1*b1b4d261SWilliam A. Kennington IIIdescription: > 2*b1b4d261SWilliam A. Kennington III Implement to enable an object. 3*b1b4d261SWilliam A. Kennington III 4*b1b4d261SWilliam A. Kennington III A d-bus object under certain circumstances may have the need to be denoted 5*b1b4d261SWilliam A. Kennington III as "disabled". So the object exists, but it's current state (described by 6*b1b4d261SWilliam A. Kennington III the object properties) can't be relied upon, until the object is "enabled" 7*b1b4d261SWilliam A. Kennington III again. What causes the object to be enabled or disabled - whether it's via 8*b1b4d261SWilliam A. Kennington III an external interface or internal logic - depends on a specific 9*b1b4d261SWilliam A. Kennington III implementation and use-case. 10*b1b4d261SWilliam A. Kennington III 11*b1b4d261SWilliam A. Kennington III An example could be a d-bus object that denotes boot settings. However let's 12*b1b4d261SWilliam A. Kennington III say there's a permanent settings object versus a one-time (the next boot) 13*b1b4d261SWilliam A. Kennington III settings object. In this case, one of these objects, typically the one which 14*b1b4d261SWilliam A. Kennington III is not supposed to be used as a default, can implement the Enable interface 15*b1b4d261SWilliam A. Kennington III so that a user can indicate whether this setting object is to be used or 16*b1b4d261SWilliam A. Kennington III not, by setting the Enabled property. 17*b1b4d261SWilliam A. Kennington IIIproperties: 18*b1b4d261SWilliam A. Kennington III - name: Enabled 19*b1b4d261SWilliam A. Kennington III type: boolean 20*b1b4d261SWilliam A. Kennington III description: > 21*b1b4d261SWilliam A. Kennington III Whether the object is enabled or not. Implementation may throw error 22*b1b4d261SWilliam A. Kennington III "NotAllowed" depends on the context how it is used. 23*b1b4d261SWilliam A. Kennington III default: false 24*b1b4d261SWilliam A. Kennington III errors: 25*b1b4d261SWilliam A. Kennington III - xyz.openbmc_project.Common.Error.NotAllowed 26