From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@linaro.org>
Subject: Re: [PATCH RFC 17/35] pl011: Initialize serial from
	ACPI SPCR table
Date: Wed, 11 Feb 2015 14:10:36 +0800
Message-ID: <54DAF25C.1050305@linaro.org>
References: <1423058539-26403-1-git-send-email-parth.dixit@linaro.org>		
	<1423058539-26403-18-git-send-email-parth.dixit@linaro.org>		
	<54D295C9.9040205@linaro.org>
	<1423136560.24924.82.camel@citrix.com>	
	<54D37E36.1020301@linaro.org> <1423147922.31546.6.camel@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1423147922.31546.6.camel@citrix.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: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Naresh Bhat <naresh.bhat@linaro.org>, tim@xen.org, xen-devel@lists.xen.org, stefano.stabellini@citrix.com, jbeulich@suse.com, parth.dixit@linaro.org, christoffer.dall@linaro.org
List-Id: xen-devel@lists.xenproject.org

Hi Ian,

On 05/02/2015 22:52, Ian Campbell wrote:
> On Thu, 2015-02-05 at 22:29 +0800, Julien Grall wrote:
>> On 05/02/2015 19:42, Ian Campbell wrote:
>>> On Wed, 2015-02-04 at 21:57 +0000, Julien Grall wrote:
>>>
>>>> I believe that most of the SPCR parsing should be generic, so maybe you
>>>> could extend the DEVICE interface to handle the ACPI case.
>>>
>>> Extending DT_DEVICE would be confusing IMHO. The answer is probably a
>>> similar but parallel ACPI_DEVICE mechanism, perhaps sharing some
>>> underlying infrastructure with DT_DEVICE.
>>
>> I was thinking to rename DT_DEVICE into something more meaningful.
>> Because infine, DT_DEVICE_START/DT_DEVICE_END doesn't do anything DT
>> specific but defined the a printed name and the device class.
>>
>> So we can extend the device framework without adding too much new code.
>
> Remember that things like the probe function are going to have different
> prototypes. It also contains things like the DT compat list which is DT
> specific.
>
> So, I think the macros should remain boot firmware specific, whether
> they fill in the same array or not is an implementation detail, but it
> would seem less error prone to split them up.

We may duplicate some fields with this. Although we are talking about 
only few bytes.

So I guess it's fine.

Regards,

-- 
Julien Grall