Hi Mark, On Mon, Jul 22, 2019 at 4:18 PM Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Fri, Jul 05, 2019 at 01:11:01PM +0800, Bin Meng wrote: > > On Fri, Jul 5, 2019 at 11:59 AM Anup Patel <Anup.Patel@xxxxxxx> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: linux-riscv <linux-riscv-bounces@xxxxxxxxxxxxxxxxxxx> On Behalf Of Bin > > > > Meng > > > > Sent: Friday, July 5, 2019 9:23 AM > > > > To: linux-riscv <linux-riscv@xxxxxxxxxxxxxxxxxxx>; devicetree > > > > <devicetree@xxxxxxxxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Mark > > > > Rutland <mark.rutland@xxxxxxx>; Albert Ou <aou@xxxxxxxxxxxxxxxxx>; > > > > Paul Walmsley <paul.walmsley@xxxxxxxxxx>; Palmer Dabbelt > > > > <palmer@xxxxxxxxxx>; Yash Shah <yash.shah@xxxxxxxxxx> > > > > Subject: [PATCH] riscv: dts: fu540-c000: Add "status" property to cpu node > > > > > > > > Per device tree spec, the "status" property property shall be present for > > > > nodes representing CPUs in a SMP configuration. This property is currently > > > > missing in cpu 1/2/3/4 node in the fu540-c000.dtsi. > > > > > > We don't need explicit "status = okay" for SOC internal devices > > > (such as PLIC, INTC, etc) which are always enabled by default. > > > > > > > Yes, that's fine because those device bindings do not require them. > > > > > Absence of "status" DT prop is treated as enabled by default. > > > > > > > But per current device tree spec, "status" in cpu node is mandatory. > > (spec uses "shall"). Missing it is a spec violation. > > I think this is a spec bug (or at least misleading wording in the spec). > > IEEE 1275 says (for status as a generic property): > > The absence of this property menas that the operational status is unknown or > okay. Yes, I checked IEEE 1275 doc, and it indeed says like you mentioned. However, it says "unknown" _or_ "okay", yet provides a definite value. > > ... and I think it's fine to treat that the same as an explicit "okay" here, as > we do generically in Linux. So what Linux does is a defacto interpretation? If everyone agrees this is a device tree spec bug, I will submit the patch to devicetree spec then. Regards, Bin