diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/networking/rds.txt | 9 | ||||
| -rw-r--r-- | Documentation/pinctrl.txt | 17 | ||||
| -rw-r--r-- | Documentation/stable_kernel_rules.txt | 10 |
3 files changed, 22 insertions, 14 deletions
diff --git a/Documentation/networking/rds.txt b/Documentation/networking/rds.txt index c67077cbeb80..e1a3d59bbe0f 100644 --- a/Documentation/networking/rds.txt +++ b/Documentation/networking/rds.txt @@ -62,11 +62,10 @@ Socket Interface ================ AF_RDS, PF_RDS, SOL_RDS - These constants haven't been assigned yet, because RDS isn't in - mainline yet. Currently, the kernel module assigns some constant - and publishes it to user space through two sysctl files - /proc/sys/net/rds/pf_rds - /proc/sys/net/rds/sol_rds + AF_RDS and PF_RDS are the domain type to be used with socket(2) + to create RDS sockets. SOL_RDS is the socket-level to be used + with setsockopt(2) and getsockopt(2) for RDS specific socket + options. fd = socket(PF_RDS, SOCK_SEQPACKET, 0); This creates a new, unbound RDS socket. diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index b8f2147b96dd..0df872a41053 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -72,7 +72,6 @@ static struct pinctrl_desc foo_desc = { .name = "foo", .pins = foo_pins, .npins = ARRAY_SIZE(foo_pins), - .maxpin = 63, .owner = THIS_MODULE, }; @@ -164,8 +163,8 @@ static const char *foo_get_group_name(struct pinctrl_dev *pctldev, } static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector, - unsigned ** const pins, - unsigned * const num_pins) + const unsigned **pins, + unsigned *num_pins) { *pins = (unsigned *) foo_groups[selector].pins; *num_pins = foo_groups[selector].num_pins; @@ -570,9 +569,8 @@ is possible to perform the requested mux setting, poke the hardware so that this happens. Pinmux drivers are required to supply a few callback functions, some are -optional. Usually the enable() and disable() functions are implemented, -writing values into some certain registers to activate a certain mux setting -for a certain pin. +optional. Usually the set_mux() function is implemented, writing values into +some certain registers to activate a certain mux setting for a certain pin. A simple driver for the above example will work by setting bits 0, 1, 2, 3 or 4 into some register named MUX to select a certain function with a certain @@ -1266,7 +1264,7 @@ The semantics of the pinctrl APIs are: Usually the pin control core handled the get/put pair and call out to the device drivers bookkeeping operations, like checking available functions and -the associated pins, whereas the enable/disable pass on to the pin controller +the associated pins, whereas select_state pass on to the pin controller driver which takes care of activating and/or deactivating the mux setting by quickly poking some registers. @@ -1363,8 +1361,9 @@ function, but with different named in the mapping as described under "Advanced mapping" above. So that for an SPI device, we have two states named "pos-A" and "pos-B". -This snippet first muxes the function in the pins defined by group A, enables -it, disables and releases it, and muxes it in on the pins defined by group B: +This snippet first initializes a state object for both groups (in foo_probe()), +then muxes the function in the pins defined by group A, and finally muxes it in +on the pins defined by group B: #include <linux/pinctrl/consumer.h> diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index 02f8331edb8b..58d0ac4df946 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -81,6 +81,16 @@ format in the sign-off area: git cherry-pick fd21073 git cherry-pick <this commit> +Also, some patches may have kernel version prerequisites. This can be +specified in the following format in the sign-off area: + + Cc: <stable@vger.kernel.org> # 3.3.x- + + The tag has the meaning of: + git cherry-pick <this commit> + + For each "-stable" tree starting with the specified version. + Following the submission: - The sender will receive an ACK when the patch has been accepted into the |