> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Likely > Sent: Monday, May 12, 2008 12:46 PM > To: Stephen Neuendorffer > Cc: linuxppc-dev@ozlabs.org; git-dev > Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core. > > On Mon, May 12, 2008 at 1:10 PM, Stephen Neuendorffer > <[EMAIL PROTECTED]> wrote: > > > > The best possibility that I see is glopping the compatibility > > information about what cores are compatible with which drivers and > > generating something. This is moderately better than blindly treating > > all cores with the same major version as interface compatible, but still > > has the potential to blindly declare that core versions are compatible > > when they are not really compatible. > > That's okay, the device tree conventions provide for that uncertainty. > If compatible includes both the *exact* version and the oldest known > *compatible* version (the one the drivers know about) then we're in > the situation where 99% of the time it just works. For the 1% of the > time when mistakes are made we still have the necessary information to > write exceptions in the code to work around bad data. This means code > only needs to changes when mistakes are discovered, not for every IP > core uprev.
My argument was that we should do this by truncating the major version, which is also an established standard that cores *should* follow, but you didn't like that. :) It makes at least as much sense as expressing the compatibility of the driver in the tree in terms of compatibility with some other random driver. In the case of the tft core in particular, there *is* no other driver AFAIK. > > I *really* don't want to put this into the device tree generator on a > > case-by-case basis, so unless there is something that can be generated > > from whatever meta-information EDK has, I think we're going to have to > > just have the explicit versions in the drivers for the time being. > > Can we post process the generated device tree with a table of known > compatibility strings (or regexps) for adding the older compatible > values? I don't expect the list will be particularly long or hard to > maintain and the code to do so should be trivial. Ug, that's just pushing the problem around. This seems as much like an argument for putting wildcards in the compatible bindings in the kernel as anything... Steve _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
