devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	linux-arm-kernel@lists.infradead.org,
	"Rob Herring" <robherring2@gmail.com>,
	"Russell King" <linux@arm.linux.org.uk>,
	"Will Deacon" <will.deacon@arm.com>,
	"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
	"Sebastian Reichel" <sre@debian.org>,
	"Pavel Machek" <pavel@ucw.cz>,
	"Andreas Färber" <afaerber@suse.de>,
	linux-omap@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
Date: Thu, 25 Jun 2015 09:18:51 +0200	[thread overview]
Message-ID: <20150625071851.GB2890@pali> (raw)
In-Reply-To: <20150625050138.GL4156@atomide.com>

On Wednesday 24 June 2015 22:01:38 Tony Lindgren wrote:
> * Pali Rohár <pali.rohar@gmail.com> [150506 04:45]:
> > On Wednesday 06 May 2015 13:04:01 Arnd Bergmann wrote:
> > > > 
> > > > It needs to be done in this code, so "system_rev" variable is set
> > > > properly...
> > > 
> > > What I mean is which code accesses this variable that early?
> > > 
> > 
> > ATAG code is doing it at same early stage, so I added it to same early
> > stage...
> 
> Yes we should do this early like the other atags.
>  
> > > > > Also, it seems strange to have a string property and then use kstrtouint
> > > > > to convert it into a number. I think it should either be specified in a DT
> > > > > binding to be a string and then have the kernel not assume that it is a number,
> > > > > or we should define it to be binary.
> > > > > 
> > > > >       Arnd
> > > > 
> > > > Variable "system_rev" is number and it always was. So chaning type will
> > > > break more parts.
> > > > 
> > > > And it is string DT property to be human readable. Some other developers
> > > > suggested for v2 to change it to string (from number).
> > > 
> > > Both of them would be human readable, you just use something else to
> > > read them ;-)
> > > 
> > > If we have a string here, we should just change all uses of system_rev
> > > in the kernel accordingly, there are only a few of them:
> 
> Let's just keep it as a hex as it was. After all it's an existing
> interface in /proc that user space programs may expect to be in
> hex format already.
> 
> Pali, care to repost the whole set again right after -rc1 with
> with rev property naming and documentation added? Just keep it
> as hex and let's forget any string conversion.
> 
> Regards,
> 
> Tony

Ok, but what do you mean to forget any string conversion?

-- 
Pali Rohár
pali.rohar@gmail.com

  reply	other threads:[~2015-06-25  7:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1430902142-17035-1-git-send-email-pali.rohar@gmail.com>
     [not found] ` <1430902142-17035-2-git-send-email-pali.rohar@gmail.com>
2015-05-06  9:31   ` [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision Arnd Bergmann
2015-05-06 10:37     ` Pali Rohár
2015-05-06 11:04       ` Arnd Bergmann
2015-05-06 11:44         ` Pali Rohár
2015-06-25  5:01           ` Tony Lindgren
2015-06-25  7:18             ` Pali Rohár [this message]
2015-06-25  7:22               ` Tony Lindgren
2015-06-25  7:27                 ` Pali Rohár
2015-06-25  7:41                   ` Tony Lindgren
     [not found]             ` <20150625050138.GL4156-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2015-07-06 12:23               ` Pali Rohár
2015-07-06 12:31                 ` Tony Lindgren
     [not found]                   ` <20150706123126.GG10705-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2015-07-06 13:12                     ` Pali Rohár
2015-07-06 13:55                       ` Tony Lindgren
2015-07-06 15:22                       ` Rob Herring
     [not found]                         ` <CAL_Jsq+ysDqxTgfW1JvG5czHa4UkZQDv1BN63iK4jvV9kDXM8w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-06 16:20                           ` Pali Rohár
2015-07-06 16:36                             ` Pali Rohár
2015-07-06 17:30                             ` Rob Herring
2015-07-06 15:20                   ` Rob Herring
2015-07-06 15:24                     ` Tony Lindgren
2015-06-25 10:03           ` Russell King - ARM Linux

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=20150625071851.GB2890@pali \
    --to=pali.rohar@gmail.com \
    --cc=afaerber@suse.de \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --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=pavel@ucw.cz \
    --cc=robherring2@gmail.com \
    --cc=sre@debian.org \
    --cc=tony@atomide.com \
    --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;
as well as URLs for NNTP newsgroup(s).