5a6b56de41
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com> #for Matt's drivers
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
103 lines
2.7 KiB
Plaintext
103 lines
2.7 KiB
Plaintext
This binding is derived from clock bindings, and based on suggestions
|
|
from Lars-Peter Clausen [1].
|
|
|
|
Sources of IIO channels can be represented by any node in the device
|
|
tree. Those nodes are designated as IIO providers. IIO consumer
|
|
nodes use a phandle and IIO specifier pair to connect IIO provider
|
|
outputs to IIO inputs. Similar to the gpio specifiers, an IIO
|
|
specifier is an array of one or more cells identifying the IIO
|
|
output on a device. The length of an IIO specifier is defined by the
|
|
value of a #io-channel-cells property in the IIO provider node.
|
|
|
|
[1] https://marc.info/?l=linux-iio&m=135902119507483&w=2
|
|
|
|
==IIO providers==
|
|
|
|
Required properties:
|
|
#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
|
|
with a single IIO output and 1 for nodes with multiple
|
|
IIO outputs.
|
|
|
|
Optional properties:
|
|
label: A symbolic name for the device.
|
|
|
|
|
|
Example for a simple configuration with no trigger:
|
|
|
|
adc: voltage-sensor@35 {
|
|
compatible = "maxim,max1139";
|
|
reg = <0x35>;
|
|
#io-channel-cells = <1>;
|
|
label = "voltage_feedback_group1";
|
|
};
|
|
|
|
Example for a configuration with trigger:
|
|
|
|
adc@35 {
|
|
compatible = "some-vendor,some-adc";
|
|
reg = <0x35>;
|
|
|
|
adc1: iio-device@0 {
|
|
#io-channel-cells = <1>;
|
|
/* other properties */
|
|
};
|
|
adc2: iio-device@1 {
|
|
#io-channel-cells = <1>;
|
|
/* other properties */
|
|
};
|
|
};
|
|
|
|
==IIO consumers==
|
|
|
|
Required properties:
|
|
io-channels: List of phandle and IIO specifier pairs, one pair
|
|
for each IIO input to the device. Note: if the
|
|
IIO provider specifies '0' for #io-channel-cells,
|
|
then only the phandle portion of the pair will appear.
|
|
|
|
Optional properties:
|
|
io-channel-names:
|
|
List of IIO input name strings sorted in the same
|
|
order as the io-channels property. Consumers drivers
|
|
will use io-channel-names to match IIO input names
|
|
with IIO specifiers.
|
|
io-channel-ranges:
|
|
Empty property indicating that child nodes can inherit named
|
|
IIO channels from this node. Useful for bus nodes to provide
|
|
and IIO channel to their children.
|
|
|
|
For example:
|
|
|
|
device {
|
|
io-channels = <&adc 1>, <&ref 0>;
|
|
io-channel-names = "vcc", "vdd";
|
|
};
|
|
|
|
This represents a device with two IIO inputs, named "vcc" and "vdd".
|
|
The vcc channel is connected to output 1 of the &adc device, and the
|
|
vdd channel is connected to output 0 of the &ref device.
|
|
|
|
==Example==
|
|
|
|
adc: max1139@35 {
|
|
compatible = "maxim,max1139";
|
|
reg = <0x35>;
|
|
#io-channel-cells = <1>;
|
|
};
|
|
|
|
...
|
|
|
|
iio-hwmon {
|
|
compatible = "iio-hwmon";
|
|
io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
|
|
<&adc 3>, <&adc 4>, <&adc 5>,
|
|
<&adc 6>, <&adc 7>, <&adc 8>,
|
|
<&adc 9>;
|
|
};
|
|
|
|
some_consumer {
|
|
compatible = "some-consumer";
|
|
io-channels = <&adc 10>, <&adc 11>;
|
|
io-channel-names = "adc1", "adc2";
|
|
};
|