All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Collins <collinsd@codeaurora.org>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: devicetree-discuss@lists.ozlabs.org,
	linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: How to represent negative values for device tree property
Date: Mon, 01 Apr 2013 17:24:19 -0700	[thread overview]
Message-ID: <515A2533.8050005@codeaurora.org> (raw)
In-Reply-To: <515A038F.2090902@wwwdotorg.org>

On 04/01/2013 03:00 PM, Stephen Warren wrote:
> On 04/01/2013 03:08 PM, David Collins wrote:
>> Hi,
>>
>> I am working on a thermal driver which needs to be able to read a
>> temperature threshold from a device tree property.  The hardware supports
>> thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
>> as I am sure others have as well, that dtc treats a '-' before an integer
>> in a dtsi file as a syntax error.  Therefore, I need some artificial way
>> to represent negative numbers in device tree.  Here are the possibilities
>> that I have thought of so far:
> 
> Doesn't the very latest dtc, which contains integer expression support,
> allow unary -? I thought that code had been imported into the kernel
> (goes and checks) yes it has. What's the error you're seeing;
> over/underflow or syntax?
> 
> That said, DT cells are supposed to be u32 not s32, so perhaps this
> isn't unexpected.

It is likely that my dtc version is out of date.  dtc -v outputs 1.2.0.  I
will try updating to a newer version of dtc.  The error that I currently
get is a syntax error: "FATAL ERROR: Unable to parse input tree".

Does the device tree binary documentation define any format for negative
numbers?  Unsigned 32-bit integers are clearly defined as bytes in
big-endian order.  I suppose that you could assume 32-bit signed integers
are 2's complement with bytes in big-endian order, but that would need to
be well defined somewhere.

Assuming that dtb has no well defined means of holding a negative integer
value, then what is the most elegant workaround to specify a negative value?

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: collinsd@codeaurora.org (David Collins)
To: linux-arm-kernel@lists.infradead.org
Subject: How to represent negative values for device tree property
Date: Mon, 01 Apr 2013 17:24:19 -0700	[thread overview]
Message-ID: <515A2533.8050005@codeaurora.org> (raw)
In-Reply-To: <515A038F.2090902@wwwdotorg.org>

On 04/01/2013 03:00 PM, Stephen Warren wrote:
> On 04/01/2013 03:08 PM, David Collins wrote:
>> Hi,
>>
>> I am working on a thermal driver which needs to be able to read a
>> temperature threshold from a device tree property.  The hardware supports
>> thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
>> as I am sure others have as well, that dtc treats a '-' before an integer
>> in a dtsi file as a syntax error.  Therefore, I need some artificial way
>> to represent negative numbers in device tree.  Here are the possibilities
>> that I have thought of so far:
> 
> Doesn't the very latest dtc, which contains integer expression support,
> allow unary -? I thought that code had been imported into the kernel
> (goes and checks) yes it has. What's the error you're seeing;
> over/underflow or syntax?
> 
> That said, DT cells are supposed to be u32 not s32, so perhaps this
> isn't unexpected.

It is likely that my dtc version is out of date.  dtc -v outputs 1.2.0.  I
will try updating to a newer version of dtc.  The error that I currently
get is a syntax error: "FATAL ERROR: Unable to parse input tree".

Does the device tree binary documentation define any format for negative
numbers?  Unsigned 32-bit integers are clearly defined as bytes in
big-endian order.  I suppose that you could assume 32-bit signed integers
are 2's complement with bytes in big-endian order, but that would need to
be well defined somewhere.

Assuming that dtb has no well defined means of holding a negative integer
value, then what is the most elegant workaround to specify a negative value?

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2013-04-02  0:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-01 21:08 How to represent negative values for device tree property David Collins
2013-04-01 21:08 ` David Collins
2013-04-01 22:00 ` Stephen Warren
2013-04-01 22:00   ` Stephen Warren
2013-04-02  0:24   ` David Collins [this message]
2013-04-02  0:24     ` David Collins
2013-04-02  6:29     ` David Gibson
2013-04-02  6:29       ` David Gibson
2013-04-02 15:36       ` Stephen Warren
2013-04-02 15:36         ` Stephen Warren
2013-04-02  6:17 ` David Gibson
2013-04-02  6:17   ` David Gibson
  -- strict thread matches above, loose matches on Subject: below --
2013-03-29 20:13 David Collins

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=515A2533.8050005@codeaurora.org \
    --to=collinsd@codeaurora.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=swarren@wwwdotorg.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.