Lines Matching +full:attribute +full:- +full:set
8 properties to user-space.
10 It defines core set of attributes, which should be applicable to (almost)
14 Each attribute has well defined meaning, up to unit of measure used. While
20 The core attribute set is subject to the standard Linux evolution (i.e.
21 if it will be found that some attribute is applicable to many power supply
22 types or their drivers, it can be added to the core set).
34 Power supply class has predefined set of attributes, this eliminates code
38 So, userspace gets predictable set of attributes and their units for any
60 +--------------------------------------------------------------------------+
61 | **Charge/Energy/Capacity - how to not confuse** |
62 +--------------------------------------------------------------------------+
66 | - `CHARGE_*` |
68 | - `ENERGY_*` |
70 | - `CAPACITY` |
71 | attribute represents capacity in *percents*, from 0 to 100. |
72 +--------------------------------------------------------------------------+
83 this attribute represents operating status (charging, full,
110 Battery driver also can use this attribute just to inform userspace
142 relative, time-based measurements.
217 Battery <-> external power supply interaction
248 Where is POWER_SUPPLY_PROP_XYZ attribute?
250 If you cannot find attribute suitable for your driver needs, feel free
261 I have some very specific attribute (e.g. battery color), should I add
262 this attribute to standard ones?
264 Most likely, no. Such attribute can be placed in the driver itself, if
265 it is useful. Of course, if the attribute in question applicable to
266 large set of batteries, provided by many drivers, and/or comes from
268 be added to the core attribute set.
275 attribute? The same question about time_to_empty/time_to_full.
285 voltage and so on. But full-fledged battery model is likely not subject