On 30.08.2013, at 15:58, Andreas Färber wrote: > Am 30.08.2013 15:53, schrieb Alexey Kardashevskiy: >> On 08/30/2013 11:26 PM, Andreas Färber wrote: >>> Am 30.08.2013 15:21, schrieb Alexander Graf: >>>> >>>> On 16.08.2013, at 00:35, Andreas Färber wrote: >>>> >>>>> Instead of relying on cpu_model, obtain the device tree node label >>>>> per CPU. Use DeviceClass::fw_name when available. This implicitly >>>>> resolves HOST@0 node labels for those CPUs through inheritance. >>>>> >>>>> Whenever DeviceClass::fw_name is not available, derive it from the CPU's >>>>> type name and fill it in for that class with a "PowerPC," prefix for >>>>> PAPR compliance. >>>> >>>> Could we just mandate the fw_name field to always be set for all classes >>>> instead? >>> >>> Sure, we can assert it. But we would then need to set fw_name for the >>> various 970 families at least, which I have been using with pseries in >>> the past. Cell and POWER6 are TODO so I'm not concerned about them. Not >>> sure about RS64 that Alexey mentioned - I wouldn't be able to test. >>> Would be bad to regress and abort with CPU models that were working okay >>> before. >> >> If we generated fw_name as it would have been done by the current helpers, >> how would anything regress? > > Well, before, you were talking about assigning "reasonable fw_name > values", and that would for me require knowledge of which value is > reasonable (i.e., correct) for a certain CPU, and I don't have boards to > check most of them. > > My proposal would be to just do it for the sPAPR-compatible (not sure if > that is what you meant with "supported"?) CPUs (because that's where we > intend to use it) and mark the ones we don't know exactly with /* ??? */ > as done elsewhere in ppc code.
Yup, we could even specifically just name them fw_name = "PowerPC,UNKNOWN"; whenever we don't know better as you were suggesting earlier. Alex
