On Sun, Dec 08, 2013 at 04:38:58PM +0000, Peter Maydell wrote: > Sorry, but there is already shipping software (kvmtool > and QEMU) which isn't emitting clock-frequency properties > for cpu nodes, based on what you documented in the kernel > doc file, which says: I didn't document anything here except this patch, I was just trying to reconcile the implementation with the documentation. > "The ARM architecture, in accordance with the ePAPR, requires > the cpus and cpu nodes to be present and contain the properties > described below." > not "must contain the properties described below and also > any others that the ePAPR spec says are mandatory". I think that's a fairly tortured way of reading the language there to be honest (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). If that really is how we want to read things then we probably ought to delete the reference to ePAPR both here and in the other binding documentation we have and fork the specs. > So I'm afraid you're stuck with this being an optional property. Like I say I think a reasonable and robust implementation shouldn't reject a device tree with it missing but that doesn't stop the device tree being out of spec. This is also the existing kernel behaviour for this property so we're stuck with it anyway and my goal here was to minimise our deviation from the spec so I introduced the minimum practical change in the process of copying it in for discoverability. This sort of situation is going to become more and more common as people actually look at device trees in production; the kernel will have to be robust against device trees that it previously accepted even if they are out of spec (and should just generally be robust in parsing). We've got to understand that the kernel will fill the role Windows does for PCs - things that run well enough with existing kernels are going to end up being released regardless of spec conformance. Kernels should be liberal in what they accept, DTs should be conservative in what they contain and both need to understand that the other is going to get it wrong some of the time. > (It's also not at all clear what a virtual machine's devicetree > should set the clock-frequency properties to anyway...) Yes, it's a poorly considered property all round. Most currently available silicon has variable clocks for the cores which is an issue with a fixed DT like FDT provides and like you say for simulators and so on it's meaningless. Ideally someone with the time/enthuisiasm will get this dealt with more sensibly in a future revision of ePAPR.
Attachment:
signature.asc
Description: Digital signature
