Re: [Xen-devel] [PATCH v01 2/3] xen/arm: add platform specific definitions for DRA7 evm board

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-06-27 at 18:50 +0100, Julien Grall wrote:
> On 06/27/2014 03:47 PM, Ian Campbell wrote:
> > On Fri, 2014-06-27 at 15:27 +0100, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 27/06/14 13:17, Ian Campbell wrote:
> >>>> +    /* OMAP Linux kernel handles devices with status "disabled" in a
> >>>> +     * weird manner - tries to reset them. While their memory ranges
> >>>> +     * are not mapped, this leads to data aborts, so skip these devices
> >>>> +     * from DT for dom0.
> >>>> +     */
> >>>> +    DT_MATCH_NOT_AVAILABLE(),
> >>>
> >>> I think this should be done in common code, either by default (if that
> >>> makes sense) or using a new quirk flag.
> >>
> >> Both of these solutions doesn't make sense to me. A device which is not 
> >> available should not be touch by the kernel. In most of the case, Linux 
> >> ignores a device which is not available (see amba/platform register code).
> >>
> >> For instance, some board has the same SOC but with different devices 
> >> enabled/disabled. In this case, there is usually a common device tree 
> >> with all enabled/disabled, and a specific device tree which override 
> >> some properties.
> >>
> >> If OMAP does weird thinks with the device tree, then we should keep it 
> >> in the platform code.
> > 
> > That's what the quirks mechanism is for IMHO.
> 
> platform_blacklist has been create to blacklist devices for a specific
> platform. I don't think other platform will do a such weird think.
> 
> handle_node is actually quite complex, there is lots of different case
> to skip a node. So I don't feel confident to add a quirk (and therefore
> few lines mores) in this function.
> 
> So unless there is a good reason to skip blacklist, that does what we
> want, I would prefer to use the current solution. And maybe we will be
> able to remove it one day...

OK then.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel