Skip to content

Commit fbf4432

Browse files
torvaldstorvalds
committed
Merge branch 'akpm' (patches from Andrew)
Merge more updates from Andrew Morton: - most of the rest of MM - a small number of misc things - lib/ updates - checkpatch - autofs updates - ipc/ updates * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (126 commits) ipc: optimize semget/shmget/msgget for lots of keys ipc/sem: play nicer with large nsops allocations ipc/sem: drop sem_checkid helper ipc: convert kern_ipc_perm.refcount from atomic_t to refcount_t ipc: convert sem_undo_list.refcnt from atomic_t to refcount_t ipc: convert ipc_namespace.count from atomic_t to refcount_t kcov: support compat processes sh: defconfig: cleanup from old Kconfig options mn10300: defconfig: cleanup from old Kconfig options m32r: defconfig: cleanup from old Kconfig options drivers/pps: use surrounding "if PPS" to remove numerous dependency checks drivers/pps: aesthetic tweaks to PPS-related content cpumask: make cpumask_next() out-of-line kmod: move #ifdef CONFIG_MODULES wrapper to Makefile kmod: split off umh headers into its own file MAINTAINERS: clarify kmod is just a kernel module loader kmod: split out umh code into its own file test_kmod: flip INT checks to be consistent test_kmod: remove paranoid UINT_MAX check on uint range processing vfat: deduplicate hex2bin() ...
2 parents c054be1 + 0cfb6ae commit fbf4432

File tree

271 files changed

+7222
-2011
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

271 files changed

+7222
-2011
lines changed

‎Documentation/devicetree/bindings/pps/pps-gpio.txt‎

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -13,8 +13,12 @@ Optional properties:
1313

1414
Example:
1515
pps {
16-
compatible = "pps-gpio";
17-
gpios = <&gpio2 6 0>;
16+
pinctrl-names = "default";
17+
pinctrl-0 = <&pinctrl_pps>;
1818

19+
gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
1920
assert-falling-edge;
21+
22+
compatible = "pps-gpio";
23+
status = "okay";
2024
};

‎Documentation/pps/pps.txt‎

Lines changed: 23 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -48,12 +48,12 @@ problem:
4848
time_pps_create().
4949

5050
This implies that the source has a /dev/... entry. This assumption is
51-
ok for the serial and parallel port, where you can do something
51+
OK for the serial and parallel port, where you can do something
5252
useful besides(!) the gathering of timestamps as it is the central
53-
task for a PPS-API. But this assumption does not work for a single
53+
task for a PPS API. But this assumption does not work for a single
5454
purpose GPIO line. In this case even basic file-related functionality
5555
(like read() and write()) makes no sense at all and should not be a
56-
precondition for the use of a PPS-API.
56+
precondition for the use of a PPS API.
5757

5858
The problem can be simply solved if you consider that a PPS source is
5959
not always connected with a GPS data source.
@@ -88,13 +88,13 @@ Coding example
8888
--------------
8989

9090
To register a PPS source into the kernel you should define a struct
91-
pps_source_info_s as follows:
91+
pps_source_info as follows:
9292

9393
static struct pps_source_info pps_ktimer_info = {
9494
.name = "ktimer",
9595
.path = "",
96-
.mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | \
97-
PPS_ECHOASSERT | \
96+
.mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT |
97+
PPS_ECHOASSERT |
9898
PPS_CANWAIT | PPS_TSFMT_TSPEC,
9999
.echo = pps_ktimer_echo,
100100
.owner = THIS_MODULE,
@@ -108,13 +108,13 @@ initialization routine as follows:
108108

109109
The pps_register_source() prototype is:
110110

111-
int pps_register_source(struct pps_source_info_s *info, int default_params)
111+
int pps_register_source(struct pps_source_info *info, int default_params)
112112

113113
where "info" is a pointer to a structure that describes a particular
114114
PPS source, "default_params" tells the system what the initial default
115115
parameters for the device should be (it is obvious that these parameters
116116
must be a subset of ones defined in the struct
117-
pps_source_info_s which describe the capabilities of the driver).
117+
pps_source_info which describe the capabilities of the driver).
118118

119119
Once you have registered a new PPS source into the system you can
120120
signal an assert event (for example in the interrupt handler routine)
@@ -142,8 +142,10 @@ If the SYSFS filesystem is enabled in the kernel it provides a new class:
142142
Every directory is the ID of a PPS sources defined in the system and
143143
inside you find several files:
144144

145-
$ ls /sys/class/pps/pps0/
146-
assert clear echo mode name path subsystem@ uevent
145+
$ ls -F /sys/class/pps/pps0/
146+
assert dev mode path subsystem@
147+
clear echo name power/ uevent
148+
147149

148150
Inside each "assert" and "clear" file you can find the timestamp and a
149151
sequence number:
@@ -154,40 +156,40 @@ sequence number:
154156
Where before the "#" is the timestamp in seconds; after it is the
155157
sequence number. Other files are:
156158

157-
* echo: reports if the PPS source has an echo function or not;
159+
* echo: reports if the PPS source has an echo function or not;
158160

159-
* mode: reports available PPS functioning modes;
161+
* mode: reports available PPS functioning modes;
160162

161-
* name: reports the PPS source's name;
163+
* name: reports the PPS source's name;
162164

163-
* path: reports the PPS source's device path, that is the device the
164-
PPS source is connected to (if it exists).
165+
* path: reports the PPS source's device path, that is the device the
166+
PPS source is connected to (if it exists).
165167

166168

167169
Testing the PPS support
168170
-----------------------
169171

170172
In order to test the PPS support even without specific hardware you can use
171-
the ktimer driver (see the client subsection in the PPS configuration menu)
173+
the pps-ktimer driver (see the client subsection in the PPS configuration menu)
172174
and the userland tools available in your distribution's pps-tools package,
173-
http://linuxpps.org , or https://github.com/ago/pps-tools .
175+
http://linuxpps.org , or https://github.com/redlab-i/pps-tools.
174176

175-
Once you have enabled the compilation of ktimer just modprobe it (if
177+
Once you have enabled the compilation of pps-ktimer just modprobe it (if
176178
not statically compiled):
177179

178-
# modprobe ktimer
180+
# modprobe pps-ktimer
179181

180182
and the run ppstest as follow:
181183

182-
$ ./ppstest /dev/pps0
184+
$ ./ppstest /dev/pps1
183185
trying PPS source "/dev/pps1"
184186
found PPS source "/dev/pps1"
185187
ok, found 1 source(s), now start fetching data...
186188
source 0 - assert 1186592699.388832443, sequence: 364 - clear 0.000000000, sequence: 0
187189
source 0 - assert 1186592700.388931295, sequence: 365 - clear 0.000000000, sequence: 0
188190
source 0 - assert 1186592701.389032765, sequence: 366 - clear 0.000000000, sequence: 0
189191

190-
Please, note that to compile userland programs you need the file timepps.h .
192+
Please note that to compile userland programs, you need the file timepps.h.
191193
This is available in the pps-tools repository mentioned above.
192194

193195

‎Documentation/rbtree.txt‎

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -193,6 +193,39 @@ Example::
193193
for (node = rb_first(&mytree); node; node = rb_next(node))
194194
printk("key=%s\n", rb_entry(node, struct mytype, node)->keystring);
195195

196+
Cached rbtrees
197+
--------------
198+
199+
Computing the leftmost (smallest) node is quite a common task for binary
200+
search trees, such as for traversals or users relying on a the particular
201+
order for their own logic. To this end, users can use 'struct rb_root_cached'
202+
to optimize O(logN) rb_first() calls to a simple pointer fetch avoiding
203+
potentially expensive tree iterations. This is done at negligible runtime
204+
overhead for maintanence; albeit larger memory footprint.
205+
206+
Similar to the rb_root structure, cached rbtrees are initialized to be
207+
empty via:
208+
209+
struct rb_root_cached mytree = RB_ROOT_CACHED;
210+
211+
Cached rbtree is simply a regular rb_root with an extra pointer to cache the
212+
leftmost node. This allows rb_root_cached to exist wherever rb_root does,
213+
which permits augmented trees to be supported as well as only a few extra
214+
interfaces:
215+
216+
struct rb_node *rb_first_cached(struct rb_root_cached *tree);
217+
void rb_insert_color_cached(struct rb_node *, struct rb_root_cached *, bool);
218+
void rb_erase_cached(struct rb_node *node, struct rb_root_cached *);
219+
220+
Both insert and erase calls have their respective counterpart of augmented
221+
trees:
222+
223+
void rb_insert_augmented_cached(struct rb_node *node, struct rb_root_cached *,
224+
bool, struct rb_augment_callbacks *);
225+
void rb_erase_augmented_cached(struct rb_node *, struct rb_root_cached *,
226+
struct rb_augment_callbacks *);
227+
228+
196229
Support for Augmented rbtrees
197230
-----------------------------
198231

0 commit comments

Comments
 (0)