/openbmc/linux/drivers/regulator/ |
H A D | devres.c | 178 struct regulator_bulk_data *consumers; member 186 regulator_bulk_free(devres->num_consumers, devres->consumers); in devm_regulator_bulk_release() 190 struct regulator_bulk_data *consumers, in _devm_regulator_bulk_get() argument 201 ret = _regulator_bulk_get(dev, num_consumers, consumers, get_type); in _devm_regulator_bulk_get() 203 devres->consumers = consumers; in _devm_regulator_bulk_get() 214 * devm_regulator_bulk_get - managed get multiple regulator consumers 217 * @num_consumers: number of consumers to register 218 * @consumers: configuration of consumers; clients are stored here. 223 * consumers in one operation with management, the regulators will 229 struct regulator_bulk_data *consumers) in devm_regulator_bulk_get() argument [all …]
|
H A D | of_regulator.c | 730 * of_regulator_bulk_get_all - get multiple regulator consumers 733 * @np: device node to search for consumers 734 * @consumers: Configuration of consumers; clients are stored here. 739 * consumers in one operation. If any of the regulators cannot be 744 struct regulator_bulk_data **consumers) in of_regulator_bulk_get_all() argument 752 *consumers = NULL; in of_regulator_bulk_get_all() 756 * second pass: fill consumers in of_regulator_bulk_get_all() 763 if (!*consumers) { in of_regulator_bulk_get_all() 774 (*consumers)[n].consumer = tmp; in of_regulator_bulk_get_all() 779 if (*consumers) in of_regulator_bulk_get_all() [all …]
|
H A D | core.c | 518 * regulator consumers 530 * Assume consumers that didn't say anything are OK in regulator_check_consumers() 2318 * or IS_ERR() condition containing errno. Other consumers will be 2323 * This is intended for use by consumers which cannot tolerate shared 2347 * This is intended for use by consumers for devices which can have 2817 * regulator enabled. Explained in example with two consumers of the same 3923 * demanded by consumers. in regulator_get_optimal_voltage() 3927 * If consumers don't provide any demands, set voltage in regulator_get_optimal_voltage() 4770 * Allow the regulator to go into bypass mode if all other consumers 4855 /* notify regulator consumers and downstream regulator consumers. [all …]
|
/openbmc/obmc-console/ |
H A D | ringbuffer.c | 48 ringbuffer_consumer_unregister(rb->consumers[0]); in ringbuffer_fini() 72 rb->consumers = reallocarray(rb->consumers, rb->n_consumers, in ringbuffer_consumer_register() 73 sizeof(*rb->consumers)); in ringbuffer_consumer_register() 75 rb->consumers[n] = rbc; in ringbuffer_consumer_register() 86 if (rb->consumers[i] == rbc) { in ringbuffer_consumer_unregister() 99 memmove(&rb->consumers[i], &rb->consumers[i + 1], in ringbuffer_consumer_unregister() 101 sizeof(*rb->consumers) * (rb->n_consumers - i)); in ringbuffer_consumer_unregister() 104 free(rb->consumers); in ringbuffer_consumer_unregister() 105 rb->consumers = NULL; in ringbuffer_consumer_unregister() 107 rb->consumers = reallocarray( in ringbuffer_consumer_unregister() [all …]
|
/openbmc/linux/Documentation/power/regulator/ |
H A D | consumer.rst | 25 Consumers can be supplied by more than one regulator e.g. codec consumer with 60 This may not disable the supply if it's shared with other consumers. The 69 consumers will be powered off. 80 Consumers can control their supply voltage by calling:: 111 Consumers can control their supply current limit by calling:: 137 Some consumers can further save system power by changing the operating mode of 138 their supply regulator to be more efficient when the consumers operating state 151 on all its consumers) and change operating mode (if necessary and permitted) 158 Most consumers will use indirect operating mode control since they have no 160 consumers. [all …]
|
H A D | overview.rst | 41 Consumers can be classified into two types:- 67 - Domain 1: Switch-1, Consumers D & E. 68 - Domain 2: Switch-2, Consumers B & C. 147 allow consumers complete control over their supply voltage and current
|
/openbmc/linux/include/linux/regulator/ |
H A D | consumer.h | 124 * is such that the HW is likely to still be working but consumers should 183 * a convenience to consumers which require multiple supplies. This 246 struct regulator_bulk_data *consumers); 248 struct regulator_bulk_data **consumers); 250 struct regulator_bulk_data *consumers); 251 void devm_regulator_bulk_put(struct regulator_bulk_data *consumers); 253 struct regulator_bulk_data *consumers); 259 struct regulator_bulk_data *consumers); 263 struct regulator_bulk_data *consumers); 265 struct regulator_bulk_data *consumers); [all …]
|
H A D | machine.h | 101 * @min_uV: Smallest voltage consumers may set. 102 * @max_uV: Largest voltage consumers may set. 106 * @min_uA: Smallest current consumers may set. 107 * @max_uA: Largest current consumers may set. 118 * @valid_modes_mask: Mask of modes which may be configured by consumers. 119 * @valid_ops_mask: Operations which may be performed by consumers. 248 * Initialisation constraints, our supply and consumers supplies.
|
/openbmc/linux/virt/lib/ |
H A D | irqbypass.c | 13 * interrupt producers and consumers to find each other to enable this sort of 26 static LIST_HEAD(consumers); 82 * with any matching token found on the IRQ consumers list. 107 list_for_each_entry(consumer, &consumers, node) { in irq_bypass_register_producer() 154 list_for_each_entry(consumer, &consumers, node) { in irq_bypass_unregister_producer() 176 * Add the provided IRQ consumer to the list of consumers and connect 196 list_for_each_entry(tmp, &consumers, node) { in irq_bypass_register_consumer() 212 list_add(&consumer->node, &consumers); in irq_bypass_register_consumer() 228 * Remove a previously registered IRQ consumer from the list of consumers 246 list_for_each_entry(tmp, &consumers, node) { in irq_bypass_unregister_consumer()
|
/openbmc/linux/Documentation/driver-api/driver-model/ |
H A D | driver.rst | 191 devices of the device have successfully probed. The list of consumers of the 197 attempt at calling sync_state(), if all the consumers of the device at that 199 away. If there are no consumers of the device during the first attempt, that 200 too is considered as "all consumers of the device have probed" and sync_state() 204 still consumers that haven't probed successfully, the sync_state() call is 205 postponed and reattempted in the future only when one or more consumers of the 207 there are one or more consumers of the device that haven't probed yet, then 214 consumers of the device have probed. Once all the consumers of the device have 216 match the aggregated software state requested by all the consumers. Hence the 221 resources like IOMMUs. For example, IOMMUs with multiple consumers (devices [all …]
|
/openbmc/linux/Documentation/driver-api/hte/ |
H A D | tegra-hte.rst | 21 below. The GPIO GTE code supports both kernel and userspace consumers. The 22 kernel space consumers can directly talk to HTE subsystem while userspace 23 consumers timestamp requests go through GPIOLIB CDEV framework to HTE 30 For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be 40 one-to-one mapping with IRQ GTE provider, consumers can simply specify the IRQ
|
/openbmc/linux/Documentation/devicetree/bindings/interconnect/ |
H A D | interconnect.txt | 5 providers/consumers properties. 16 consumers, such as in the case where two network-on-chip fabrics interface 37 = interconnect consumers = 39 The interconnect consumers are device nodes which dynamically express their 55 order as the interconnects property. Consumers drivers will use
|
/openbmc/docs/designs/ |
H A D | certificate-revocation-list.md | 46 consumers which use old CRLs to refresh with the newly given CRLs 70 install multiple CRLs and notify consumers. The notification process is the 71 existing behaviour which phosphor-certificate-manager uses to tell consumers 75 replace all existing CRLs with multiple new CRLs and notify consumers 78 delete all existing CRLs and notify consumers
|
H A D | physical-topology.md | 59 phosphor-dbus-interfaces, inventory managers, and inventory consumers such as 129 ### Inventory consumers 166 complexity of consumers of this information since they would have to support 179 consumers to understand the topology. 186 change. If consumers of inventory data such as bmcweb do not find the new
|
/openbmc/linux/Documentation/driver-api/ |
H A D | reset.rst | 19 consumers. 63 When requesting reset controls, consumers can use symbolic names for their 98 Note that since multiple consumers may be using a shared reset control, there 111 In general, these resets can not be shared between multiple consumers, since 118 All further calls to this function have no effect until all consumers have 181 Reset consumers can control a reset line using an opaque reset control handle, 184 Given the reset control, consumers can call reset_control_assert() and
|
H A D | regulator.rst | 68 When requesting regulators consumers use symbolic names for their 83 Note that since multiple consumers may be using a regulator and machine 126 consumers on a given system and what the valid operating parameters are 144 consumers are rated for. 151 static consumers.
|
H A D | device_link.rst | 177 device links from the hotplug ports (consumers) to the NHI device 231 entire sub-graph below it (all children and consumers of the consumer) 237 on the consumer or any children or consumers of the consumer. 274 * When a supplier device is bound to a driver, links to its consumers 301 * Before a supplier's driver is removed, links to consumers that are not 305 This prevents the consumers from binding. 308 Consumers that are bound are freed from their driver; consumers that are 312 Once all links to consumers are in ``DL_STATE_SUPPLIER_UNBIND`` state,
|
H A D | interconnect.rst | 72 Interconnect consumers are the entities which make use of the data paths exposed 73 by the providers. The consumers send requests to providers requesting various 74 throughput, latency and priority. Usually the consumers are device drivers, that 87 Interconnect consumers 90 Interconnect consumers are the clients which use the interconnect APIs to
|
H A D | pwm.rst | 21 consumers to providers, as given in the following example:: 38 Consumers use the pwm_get() function and pass to it the consumer device or a 69 consumers to get the actually implemented settings. 79 All consumers should really be reconfiguring the PWM upon resume as 160 consumers should implement it as described in the "Using PWMs" section.
|
/openbmc/linux/scripts/ |
H A D | dev-needs.sh | 104 CONSUMERS+=($PARENT) 138 CONSUMERS+=($SUPPLIER) 264 CONSUMERS=($@) 270 while [ $i -lt ${#CONSUMERS[@]} ] 272 CONSUMER=$(realpath ${CONSUMERS[$i]}) 289 # Add suppliers to CONSUMERS list and output the consumer details.
|
/openbmc/linux/drivers/soc/microchip/ |
H A D | mpfs-sys-controller.c | 33 struct kref consumers; member 89 container_of(kref, struct mpfs_sys_controller, consumers); in mpfs_sys_controller_delete() 99 kref_put(&sys_controller->consumers, mpfs_sys_controller_delete); in mpfs_sys_controller_put() 137 kref_init(&sys_controller->consumers); in mpfs_sys_controller_probe() 185 if (!kref_get_unless_zero(&sys_controller->consumers)) in mpfs_sys_controller_get()
|
/openbmc/linux/Documentation/infiniband/ |
H A D | core_locking.rst | 29 consumers: 60 consumers are not required to perform any serialization. However, 96 Upper level protocol consumers may not sleep in a callback. 102 consumers when it calls ib_register_device(), all initialization
|
/openbmc/linux/Documentation/crypto/ |
H A D | intro.rst | 25 - consumers requesting cryptographic services 28 called by consumers using the kernel crypto API 30 This specification is intended for consumers of the kernel crypto API as
|
/openbmc/u-boot/doc/device-tree-bindings/reset/ |
H A D | reset.txt | 20 A word on where to place reset signal consumers in device tree: It is possible 45 = Reset consumers = 56 the resets property. Consumers drivers will use reset-names to
|
/openbmc/linux/Documentation/devicetree/bindings/reset/ |
H A D | reset.txt | 20 A word on where to place reset signal consumers in device tree: It is possible 45 = Reset consumers = 56 the resets property. Consumers drivers will use reset-names to
|