Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 67706
b: refs/heads/master
c: 408af0d
h: refs/heads/master
v: v3
  • Loading branch information
Linus Torvalds committed Oct 12, 2007
1 parent 993f889 commit 2fb3ed5
Show file tree
Hide file tree
Showing 4,125 changed files with 287,365 additions and 87,023 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
2 changes: 1 addition & 1 deletion [refs]
View file
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 77f1fd6ecd04556cbac1ca72e7a284ae313ea538
refs/heads/master: 408af0dab78ef4145203b849d6bfd3195f6e3ec9
31 changes: 31 additions & 0 deletions trunk/CREDITS
View file
Original file line number Diff line number Diff line change
Expand Up @@ -665,6 +665,11 @@ D: Minor updates to SCSI types, added /proc/pid/maps protection
S: (ask for current address)
S: USA

N: Robin Cornelius
E: robincornelius@users.sourceforge.net
D: Ralink rt2x00 WLAN driver
S: Cornwall, U.K.

N: Mark Corner
E: mcorner@umich.edu
W: http://www.eecs.umich.edu/~mcorner/
Expand All @@ -679,6 +684,11 @@ D: Kernel module SMART utilities
S: Santa Cruz, California
S: USA

N: Luis Correia
E: lfcorreia@users.sf.net
D: Ralink rt2x00 WLAN driver
S: Belas, Portugal

N: Alan Cox
W: http://www.linux.org.uk/diary/
D: Linux Networking (0.99.10->2.0.29)
Expand Down Expand Up @@ -833,6 +843,12 @@ S: Lancs
S: PR4 6AX
S: United Kingdom

N: Ivo van Doorn
E: IvDoorn@gmail.com
W: http://www.mendiosus.nl
D: Ralink rt2x00 WLAN driver
S: Haarlem, The Netherlands

N: John G Dorsey
E: john+@cs.cmu.edu
D: ARM Linux ports to Assabet/Neponset, Spot
Expand Down Expand Up @@ -3517,6 +3533,12 @@ S: Maastrichterweg 63
S: 5554 GG Valkenswaard
S: The Netherlands

N: Mark Wallis
E: mwallis@serialmonkey.com
W: http://mark.serialmonkey.com
D: Ralink rt2x00 WLAN driver
S: Newcastle, Australia

N: Peter Shaobo Wang
E: pwang@mmdcorp.com
W: http://www.mmdcorp.com/pw/linux
Expand Down Expand Up @@ -3651,6 +3673,15 @@ S: Alte Regensburger Str. 11a
S: 93149 Nittenau
S: Germany

N: Gertjan van Wingerde
E: gwingerde@home.nl
D: Ralink rt2x00 WLAN driver
D: Minix V2 file-system
D: Misc fixes
S: Geessinkweg 177
S: 7544 TX Enschede
S: The Netherlands

N: Lars Wirzenius
E: liw@iki.fi
D: Linux System Administrator's Guide, author, former maintainer
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/DocBook/Makefile
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
procfs-guide.xml writing_usb_driver.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml
genericirq.xml s390-drivers.xml

###
# The build process is as follows (targets):
Expand Down
8 changes: 7 additions & 1 deletion trunk/Documentation/DocBook/kernel-api.tmpl
View file
Original file line number Diff line number Diff line change
Expand Up @@ -240,17 +240,23 @@ X!Ilib/string.c
<sect1><title>Driver Support</title>
!Enet/core/dev.c
!Enet/ethernet/eth.c
!Enet/sched/sch_generic.c
!Iinclude/linux/etherdevice.h
!Iinclude/linux/netdevice.h
</sect1>
<sect1><title>PHY Support</title>
!Edrivers/net/phy/phy.c
!Idrivers/net/phy/phy.c
!Edrivers/net/phy/phy_device.c
!Idrivers/net/phy/phy_device.c
!Edrivers/net/phy/mdio_bus.c
!Idrivers/net/phy/mdio_bus.c
</sect1>
<!-- FIXME: Removed for now since no structured comments in source
<sect1><title>Wireless</title>
X!Enet/core/wireless.c
-->
</sect1>
-->
<sect1><title>Synchronous PPP</title>
!Edrivers/net/wan/syncppp.c
</sect1>
Expand Down
149 changes: 149 additions & 0 deletions trunk/Documentation/DocBook/s390-drivers.tmpl
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,149 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>

<book id="s390drivers">
<bookinfo>
<title>Writing s390 channel device drivers</title>

<authorgroup>
<author>
<firstname>Cornelia</firstname>
<surname>Huck</surname>
<affiliation>
<address>
<email>cornelia.huck@de.ibm.com</email>
</address>
</affiliation>
</author>
</authorgroup>

<copyright>
<year>2007</year>
<holder>IBM Corp.</holder>
</copyright>

<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later
version.
</para>

<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>

<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>

<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>

<toc></toc>

<chapter id="intro">
<title>Introduction</title>
<para>
This document describes the interfaces available for device drivers that
drive s390 based channel attached devices. This includes interfaces for
interaction with the hardware and interfaces for interacting with the
common driver core. Those interfaces are provided by the s390 common I/O
layer.
</para>
<para>
The document assumes a familarity with the technical terms associated
with the s390 channel I/O architecture. For a description of this
architecture, please refer to the "z/Architecture: Principles of
Operation", IBM publication no. SA22-7832.
</para>
<para>
While most I/O devices on a s390 system are typically driven through the
channel I/O mechanism described here, there are various other methods
(like the diag interface). These are out of the scope of this document.
</para>
<para>
Some additional information can also be found in the kernel source
under Documentation/s390/driver-model.txt.
</para>
</chapter>
<chapter id="ccw">
<title>The ccw bus</title>
<para>
The ccw bus typically contains the majority of devices available to
a s390 system. Named after the channel command word (ccw), the basic
command structure used to address its devices, the ccw bus contains
so-called channel attached devices. They are addressed via subchannels,
visible on the css bus. A device driver, however, will never interact
with the subchannel directly, but only via the device on the ccw bus,
the ccw device.
</para>
<sect1 id="channelIO">
<title>I/O functions for channel-attached devices</title>
<para>
Some hardware structures have been translated into C structures for use
by the common I/O layer and device drivers. For more information on
the hardware structures represented here, please consult the Principles
of Operation.
</para>
!Iinclude/asm-s390/cio.h
</sect1>
<sect1 id="ccwdev">
<title>ccw devices</title>
<para>
Devices that want to initiate channel I/O need to attach to the ccw bus.
Interaction with the driver core is done via the common I/O layer, which
provides the abstractions of ccw devices and ccw device drivers.
</para>
<para>
The functions that initiate or terminate channel I/O all act upon a
ccw device structure. Device drivers must not bypass those functions
or strange side effects may happen.
</para>
!Iinclude/asm-s390/ccwdev.h
!Edrivers/s390/cio/device.c
!Edrivers/s390/cio/device_ops.c
</sect1>
<sect1 id="cmf">
<title>The channel-measurement facility</title>
<para>
The channel-measurement facility provides a means to collect
measurement data which is made available by the channel subsystem
for each channel attached device.
</para>
!Iinclude/asm-s390/cmb.h
!Edrivers/s390/cio/cmf.c
</sect1>
</chapter>

<chapter id="ccwgroup">
<title>The ccwgroup bus</title>
<para>
The ccwgroup bus only contains artificial devices, created by the user.
Many networking devices (e.g. qeth) are in fact composed of several
ccw devices (like read, write and data channel for qeth). The
ccwgroup bus provides a mechanism to create a meta-device which
contains those ccw devices as slave devices and can be associated
with the netdevice.
</para>
<sect1 id="ccwgroupdevices">
<title>ccw group devices</title>
!Iinclude/asm-s390/ccwgroup.h
!Edrivers/s390/cio/ccwgroup.c
</sect1>
</chapter>

</book>
20 changes: 10 additions & 10 deletions trunk/Documentation/block/biodoc.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -477,9 +477,9 @@ With this multipage bio design:
the same bi_io_vec array, but with the index and size accordingly modified)
- A linked list of bios is used as before for unrelated merges (*) - this
avoids reallocs and makes independent completions easier to handle.
- Code that traverses the req list needs to make a distinction between
segments of a request (bio_for_each_segment) and the distinct completion
units/bios (rq_for_each_bio).
- Code that traverses the req list can find all the segments of a bio
by using rq_for_each_segment. This handles the fact that a request
has multiple bios, each of which can have multiple segments.
- Drivers which can't process a large bio in one shot can use the bi_idx
field to keep track of the next bio_vec entry to process.
(e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)
Expand Down Expand Up @@ -664,14 +664,14 @@ in lvm or md.

3.2.1 Traversing segments and completion units in a request

The macros bio_for_each_segment() and rq_for_each_bio() should be used for
traversing the bios in the request list (drivers should avoid directly
trying to do it themselves). Using these helpers should also make it easier
to cope with block changes in the future.
The macro rq_for_each_segment() should be used for traversing the bios
in the request list (drivers should avoid directly trying to do it
themselves). Using these helpers should also make it easier to cope
with block changes in the future.

rq_for_each_bio(bio, rq)
bio_for_each_segment(bio_vec, bio, i)
/* bio_vec is now current segment */
struct req_iterator iter;
rq_for_each_segment(bio_vec, rq, iter)
/* bio_vec is now current segment */

I/O completion callbacks are per-bio rather than per-segment, so drivers
that traverse bio chains on completion need to keep that in mind. Drivers
Expand Down
11 changes: 9 additions & 2 deletions trunk/Documentation/block/ioprio.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -86,8 +86,15 @@ extern int sys_ioprio_get(int, int);
#error "Unsupported arch"
#endif

_syscall3(int, ioprio_set, int, which, int, who, int, ioprio);
_syscall2(int, ioprio_get, int, which, int, who);
static inline int ioprio_set(int which, int who, int ioprio)
{
return syscall(__NR_ioprio_set, which, who, ioprio);
}

static inline int ioprio_get(int which, int who)
{
return syscall(__NR_ioprio_get, which, who);
}

enum {
IOPRIO_CLASS_NONE,
Expand Down
Loading

0 comments on commit 2fb3ed5

Please sign in to comment.