From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754140AbdBVGFx (ORCPT ); Wed, 22 Feb 2017 01:05:53 -0500 Received: from mail-qk0-f178.google.com ([209.85.220.178]:36417 "EHLO mail-qk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbdBVGFo (ORCPT ); Wed, 22 Feb 2017 01:05:44 -0500 MIME-Version: 1.0 In-Reply-To: <1CC272501B5BC543A05DB90AA509DED50B010C@fmsmsx122.amr.corp.intel.com> References: <20170218023010.GA8244@live.com> <1CC272501B5BC543A05DB90AA509DED50AF5EC@fmsmsx122.amr.corp.intel.com> <20170218204509.GA32544@live.com> <1CC272501B5BC543A05DB90AA509DED50B005A@fmsmsx122.amr.corp.intel.com> <20170222051201.GB29755@obsidianresearch.com> <1CC272501B5BC543A05DB90AA509DED50B010C@fmsmsx122.amr.corp.intel.com> From: Moritz Fischer Date: Tue, 21 Feb 2017 22:05:42 -0800 Message-ID: Subject: Re: [RFC 7/8] fpga-region: add sysfs interface To: "Nadathur, Sundar" Cc: Jason Gunthorpe , Alan Tull , Yves Vandervennet , "matthew.gerlach@linux.intel.com" , linux-kernel , "linux-fpga@vger.kernel.org" , "Marek Va??ut" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 21, 2017 at 9:46 PM, Nadathur, Sundar wrote: > On February 21, 2017 9:39 PM, Moritz Fischer wrote: > >> TLV Seems easy enough. To give an update, I played with fdt a bit to see how >> far I get in half an hour. I got bool / int / strings to work quite fast (~30mins). >> Please disregard the horrible hackyness of this ... >> [...] >> So I'm fairly convinced I can make this work, TVLs seem like it could work, >> too. >> >> > So far the only thing we know we need is a 'bool' for encrypted and a >> > stringish guid thing for partial reconfiguration. > > These things have a way of growing beyond their original anticipated needs. True. But yeah, not sure about the requirement for a tree, maybe it is overkill. > Say we upstream a metadata parser. Subsequently, an FPGA image is released with an additional metadata field that the upstreamed version does not handle. How will this be handled if the metadata were in FDT or KVP format? The code above will gently ignore it, as I said I spent about half an hour on writing that, just to prove to myself it can be done easily. Logically I don't see anything wrong with ignoring features from the future. But if one insisted one could make a compatibility number part of the required properties I suppose and error out instead. There are examples of optional properties in the devicetree parsing code in the kernel. That being said older drivers / fpga-mgr will not deal with newer features. TLV / KV or whatever doesn't change this fact, or am I missing something? Adding new properties to devicetrees is a well known exercise to cope with newer versions or variations of hardware and happens all the time in the kernel. Older kernels will just ignore them. Thanks, Moritz