On 8 December 2013 21:50, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Sun, Dec 08, 2013 at 07:51:59PM +0000, Peter Maydell wrote: >> On 8 December 2013 19:22, Mark Brown <broonie@xxxxxxxxxx> wrote: >> > (and doesn't reflect the actual deployed code reading the binding >> > which does use this property without documentation outside ePAPR and does >> > warn if it's absent) > >> This code should be fixed, then... (I'm pretty sure the kernel >> has not always warned about the absence of this property, >> or there would not be such a wide prevalence of DTs and >> DT generating code which omitted it.) > > Too late for that, it's shipping in stable kernels. > There does come a point where it's just nitpicking and not helpful but > if it has a substantial effect on functionality then it's useful. In > this case suppressing the warning for non-asymmetric systems might be > sensible. Hmm, so "mandatory for non-symmetric [I assume you mean that and not really 'non-asymmetric'?], otherwise optional" ? I think that would be reasonable and preserve backwards compatibility. > For all practical purposes it is currently optional but the spec says > it is mandatory. I would rather err on the side of not changing the > documentation in case someone does work based on ePAPR and/or an old > kernel and since doing that keeps the spec more stable even if we do > implement in a more tolerant fashion within Linux (as we should). As I say, I don't think your specification currently does say it is mandatory. If the documentation doesn't clearly list it as a mandatory parameter, and a large number of people writing DTS files or DT generation code haven't put it in, and the kernel didn't complain about it not being present for a long long time, then de facto it is optional, and you should make your documentation conform with reality and fix bugs where the kernel isn't coping with that. thanks -- PMM -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
