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. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
