From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH V4] ns16550: Add support for UART present in
 Broadcom TruManage capable NetXtreme chips
Date: Fri, 22 Nov 2013 13:09:45 +0000
Message-ID: <528F5799.6010207@citrix.com>
References: <1385074236-2100-1-git-send-email-Aravind.Gopalakrishnan@amd.com>
	<528F3593.1090108@citrix.com>
	<528F58BE0200007800105CD2@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <528F58BE0200007800105CD2@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>, xen-devel@lists.xen.org, Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>, Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>, sherry.hurwitz@amd.com, shurd@broadcom.com
List-Id: xen-devel@lists.xenproject.org

On 22/11/13 12:14, Jan Beulich wrote:
>>>> On 22.11.13 at 11:44, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 21/11/13 22:50, Aravind Gopalakrishnan wrote:
>>>      if ( uart->remapped_io_base )
>>> +    {
>>> +        sfn = paddr_to_pfn((unsigned long) uart->io_base + PAGE_SIZE);
>>> +        efn = paddr_to_pfn((unsigned long) uart->io_base + uart->io_size - 1);
>>> +        if ( iomem_deny_access(dom0, sfn, efn) != 0 )
>>> +            BUG();
>> BUG_ON(!iomem_deny_access(dom0, sfn, efn))
> Actually, we had more or less agreed to avoid side effects in
> ASSERT() and BUG_ON() expressions (to eliminate the ambiguity
> whether such expressions get always evaluated).

ASSERT()s certain, as the non-debug builds will optimise away call.

BUG/WARN_ON()s are different - they will be executed in all cases.

>
>> is slightly more compact, and has the advantage of showing the action
>> which failed in the BUG message.
> Since when does BUG() should any expression?

Hmm - they don't do they.  I was getting my BUG()s and ASSERTS()s mixed up.