Skip to content

Commit ef1417a

Browse files
torvaldstorvalds
committed
Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull leftover IRQ fixes from Ingo Molnar: "Two (minor) fixlets that missed v3.12" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq: Set the irq thread policy without checking CAP_SYS_NICE irq: DocBook/genericirq.tmpl: Correct various typos
2 parents 1006fae + bbfe65c commit ef1417a

2 files changed

Lines changed: 33 additions & 33 deletions

File tree

‎Documentation/DocBook/genericirq.tmpl‎

Lines changed: 32 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -87,7 +87,7 @@
8787
<chapter id="rationale">
8888
<title>Rationale</title>
8989
<para>
90-
The original implementation of interrupt handling in Linux is using
90+
The original implementation of interrupt handling in Linux uses
9191
the __do_IRQ() super-handler, which is able to deal with every
9292
type of interrupt logic.
9393
</para>
@@ -111,19 +111,19 @@
111111
</itemizedlist>
112112
</para>
113113
<para>
114-
This split implementation of highlevel IRQ handlers allows us to
114+
This split implementation of high-level IRQ handlers allows us to
115115
optimize the flow of the interrupt handling for each specific
116-
interrupt type. This reduces complexity in that particular codepath
116+
interrupt type. This reduces complexity in that particular code path
117117
and allows the optimized handling of a given type.
118118
</para>
119119
<para>
120120
The original general IRQ implementation used hw_interrupt_type
121121
structures and their ->ack(), ->end() [etc.] callbacks to
122122
differentiate the flow control in the super-handler. This leads to
123-
a mix of flow logic and lowlevel hardware logic, and it also leads
124-
to unnecessary code duplication: for example in i386, there is a
125-
ioapic_level_irq and a ioapic_edge_irq irq-type which share many
126-
of the lowlevel details but have different flow handling.
123+
a mix of flow logic and low-level hardware logic, and it also leads
124+
to unnecessary code duplication: for example in i386, there is an
125+
ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many
126+
of the low-level details but have different flow handling.
127127
</para>
128128
<para>
129129
A more natural abstraction is the clean separation of the
@@ -132,23 +132,23 @@
132132
<para>
133133
Analysing a couple of architecture's IRQ subsystem implementations
134134
reveals that most of them can use a generic set of 'irq flow'
135-
methods and only need to add the chip level specific code.
135+
methods and only need to add the chip-level specific code.
136136
The separation is also valuable for (sub)architectures
137-
which need specific quirks in the irq flow itself but not in the
138-
chip-details - and thus provides a more transparent IRQ subsystem
137+
which need specific quirks in the IRQ flow itself but not in the
138+
chip details - and thus provides a more transparent IRQ subsystem
139139
design.
140140
</para>
141141
<para>
142-
Each interrupt descriptor is assigned its own highlevel flow
142+
Each interrupt descriptor is assigned its own high-level flow
143143
handler, which is normally one of the generic
144-
implementations. (This highlevel flow handler implementation also
144+
implementations. (This high-level flow handler implementation also
145145
makes it simple to provide demultiplexing handlers which can be
146146
found in embedded platforms on various architectures.)
147147
</para>
148148
<para>
149149
The separation makes the generic interrupt handling layer more
150150
flexible and extensible. For example, an (sub)architecture can
151-
use a generic irq-flow implementation for 'level type' interrupts
151+
use a generic IRQ-flow implementation for 'level type' interrupts
152152
and add a (sub)architecture specific 'edge type' implementation.
153153
</para>
154154
<para>
@@ -172,9 +172,9 @@
172172
<para>
173173
There are three main levels of abstraction in the interrupt code:
174174
<orderedlist>
175-
<listitem><para>Highlevel driver API</para></listitem>
176-
<listitem><para>Highlevel IRQ flow handlers</para></listitem>
177-
<listitem><para>Chiplevel hardware encapsulation</para></listitem>
175+
<listitem><para>High-level driver API</para></listitem>
176+
<listitem><para>High-level IRQ flow handlers</para></listitem>
177+
<listitem><para>Chip-level hardware encapsulation</para></listitem>
178178
</orderedlist>
179179
</para>
180180
<sect1 id="Interrupt_control_flow">
@@ -189,16 +189,16 @@
189189
which are assigned to this interrupt.
190190
</para>
191191
<para>
192-
Whenever an interrupt triggers, the lowlevel arch code calls into
193-
the generic interrupt code by calling desc->handle_irq().
194-
This highlevel IRQ handling function only uses desc->irq_data.chip
192+
Whenever an interrupt triggers, the low-level architecture code calls
193+
into the generic interrupt code by calling desc->handle_irq().
194+
This high-level IRQ handling function only uses desc->irq_data.chip
195195
primitives referenced by the assigned chip descriptor structure.
196196
</para>
197197
</sect1>
198198
<sect1 id="Highlevel_Driver_API">
199-
<title>Highlevel Driver API</title>
199+
<title>High-level Driver API</title>
200200
<para>
201-
The highlevel Driver API consists of following functions:
201+
The high-level Driver API consists of following functions:
202202
<itemizedlist>
203203
<listitem><para>request_irq()</para></listitem>
204204
<listitem><para>free_irq()</para></listitem>
@@ -216,7 +216,7 @@
216216
</para>
217217
</sect1>
218218
<sect1 id="Highlevel_IRQ_flow_handlers">
219-
<title>Highlevel IRQ flow handlers</title>
219+
<title>High-level IRQ flow handlers</title>
220220
<para>
221221
The generic layer provides a set of pre-defined irq-flow methods:
222222
<itemizedlist>
@@ -228,7 +228,7 @@
228228
<listitem><para>handle_edge_eoi_irq</para></listitem>
229229
<listitem><para>handle_bad_irq</para></listitem>
230230
</itemizedlist>
231-
The interrupt flow handlers (either predefined or architecture
231+
The interrupt flow handlers (either pre-defined or architecture
232232
specific) are assigned to specific interrupts by the architecture
233233
either during bootup or during device initialization.
234234
</para>
@@ -297,7 +297,7 @@ desc->irq_data.chip->irq_unmask();
297297
<para>
298298
handle_fasteoi_irq provides a generic implementation
299299
for interrupts, which only need an EOI at the end of
300-
the handler
300+
the handler.
301301
</para>
302302
<para>
303303
The following control flow is implemented (simplified excerpt):
@@ -394,7 +394,7 @@ if (desc->irq_data.chip->irq_eoi)
394394
The generic functions are intended for 'clean' architectures and chips,
395395
which have no platform-specific IRQ handling quirks. If an architecture
396396
needs to implement quirks on the 'flow' level then it can do so by
397-
overriding the highlevel irq-flow handler.
397+
overriding the high-level irq-flow handler.
398398
</para>
399399
</sect2>
400400
<sect2 id="Delayed_interrupt_disable">
@@ -419,24 +419,24 @@ if (desc->irq_data.chip->irq_eoi)
419419
</sect2>
420420
</sect1>
421421
<sect1 id="Chiplevel_hardware_encapsulation">
422-
<title>Chiplevel hardware encapsulation</title>
422+
<title>Chip-level hardware encapsulation</title>
423423
<para>
424-
The chip level hardware descriptor structure irq_chip
424+
The chip-level hardware descriptor structure irq_chip
425425
contains all the direct chip relevant functions, which
426426
can be utilized by the irq flow implementations.
427427
<itemizedlist>
428428
<listitem><para>irq_ack()</para></listitem>
429429
<listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
430430
<listitem><para>irq_mask()</para></listitem>
431431
<listitem><para>irq_unmask()</para></listitem>
432-
<listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem>
432+
<listitem><para>irq_eoi() - Optional, required for EOI flow handlers</para></listitem>
433433
<listitem><para>irq_retrigger() - Optional</para></listitem>
434434
<listitem><para>irq_set_type() - Optional</para></listitem>
435435
<listitem><para>irq_set_wake() - Optional</para></listitem>
436436
</itemizedlist>
437437
These primitives are strictly intended to mean what they say: ack means
438438
ACK, masking means masking of an IRQ line, etc. It is up to the flow
439-
handler(s) to use these basic units of lowlevel functionality.
439+
handler(s) to use these basic units of low-level functionality.
440440
</para>
441441
</sect1>
442442
</chapter>
@@ -445,7 +445,7 @@ if (desc->irq_data.chip->irq_eoi)
445445
<title>__do_IRQ entry point</title>
446446
<para>
447447
The original implementation __do_IRQ() was an alternative entry
448-
point for all types of interrupts. It not longer exists.
448+
point for all types of interrupts. It no longer exists.
449449
</para>
450450
<para>
451451
This handler turned out to be not suitable for all
@@ -468,11 +468,11 @@ if (desc->irq_data.chip->irq_eoi)
468468
<chapter id="genericchip">
469469
<title>Generic interrupt chip</title>
470470
<para>
471-
To avoid copies of identical implementations of irq chips the
471+
To avoid copies of identical implementations of IRQ chips the
472472
core provides a configurable generic interrupt chip
473473
implementation. Developers should check carefuly whether the
474474
generic chip fits their needs before implementing the same
475-
functionality slightly different themself.
475+
functionality slightly differently themselves.
476476
</para>
477477
!Ekernel/irq/generic-chip.c
478478
</chapter>

‎kernel/irq/manage.c‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -956,7 +956,7 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
956956
goto out_mput;
957957
}
958958

959-
sched_setscheduler(t, SCHED_FIFO, &param);
959+
sched_setscheduler_nocheck(t, SCHED_FIFO, &param);
960960

961961
/*
962962
* We keep the reference to the task struct even if

0 commit comments

Comments
 (0)