1. CCW devices¶

All devices which can be addressed by means of ccws are called ‘CCW devices’ -even if they aren’t actually driven by ccws.

All ccw devices are accessed via a subchannel, this is reflected in thestructures under devices/:

devices/   - system/   - css0/         - 0.0.0000/0.0.0815/         - 0.0.0001/0.0.4711/         - 0.0.0002/         - 0.1.0000/0.1.1234/         ...         - defunct/

In this example, device 0815 is accessed via subchannel 0 in subchannel set 0,device 4711 via subchannel 1 in subchannel set 0, and subchannel 2 is a non-I/Osubchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1.

The subchannel named ‘defunct’ does not represent any real subchannel on thesystem; it is a pseudo subchannel where disconnected ccw devices are moved toif they are displaced by another ccw device becoming operational on theirformer subchannel. The ccw devices will be moved again to a proper subchannelif they become operational again on that subchannel.

You should address a ccw device via its bus id (e.g. 0.0.4711); the device canbe found under bus/ccw/devices/.

All ccw devices export some data via sysfs.

cutype:

The control unit type / model.

devtype:

The device type / model, if applicable.

availability:

Can be ‘good’ or ‘boxed’; ‘no path’ or ‘no device’ fordisconnected devices.

online:

An interface to set the device online and offline.In the special case of the device being disconnected (see thenotify function under 1.2), piping 0 to online will forcibly deletethe device.

The device drivers can add entries to export per-device data and interfaces.

There is also some data exported on a per-subchannel basis (see underbus/css/devices/):

chpids:

Via which chpids the device is connected.

pimpampom:

The path installed, path available and path operational masks.

There also might be additional data, for example for block devices.

1.1 Bringing up a ccw device¶

This is done in several steps.

1. Each driver can provide one or more parameter interfaces where parameters canbe specified. These interfaces are also in the driver’s responsibility.
2. After a. has been performed, if necessary, the device is finally brought upvia the ‘online’ interface.

1.2 Writing a driver for ccw devices¶

The basic struct ccw_device and struct ccw_driver data structures can be foundunder include/asm/ccwdev.h:

struct ccw_device {      spinlock_t *ccwlock;      struct ccw_device_private *private;      struct ccw_device_id id;      struct ccw_driver *drv;      struct device dev;      int online;      void (*handler) (struct ccw_device *dev, unsigned long intparm,                       struct irb *irb);};struct ccw_driver {      struct module *owner;      struct ccw_device_id *ids;      int (*probe) (struct ccw_device *);      int (*remove) (struct ccw_device *);      int (*set_online) (struct ccw_device *);      int (*set_offline) (struct ccw_device *);      int (*notify) (struct ccw_device *, int);      struct device_driver driver;      char *name;};

The ‘private’ field contains data needed for internal i/o operation only, andis not available to the device driver.

Each driver should declare in a MODULE_DEVICE_TABLE into which CU types/modelsand/or device types/models it is interested. This information can later be foundin the struct ccw_device_id fields:

struct ccw_device_id {      __u16   match_flags;      __u16   cu_type;      __u16   dev_type;      __u8    cu_model;      __u8    dev_model;      unsigned long driver_info;};

The functions in ccw_driver should be used in the following way:

probe:

This function is called by the device layer for each device the driveris interested in. The driver should only allocate private structuresto put in dev->driver_data and create attributes (if needed). Also,the interrupt handler (see below) should be set here.

int (*probe) (struct ccw_device *cdev);

Parameters:

cdev

• the device to be probed.

remove:

This function is called by the device layer upon removal of the driver,the device or the module. The driver should perform cleanups here.

int (*remove) (struct ccw_device *cdev);

Parameters:

cdev

• the device to be removed.

set_online:

This function is called by the common I/O layer when the device isactivated via the ‘online’ attribute. The driver should finallysetup and activate the device here.

int (*set_online) (struct ccw_device *);

Parameters:

cdev

• the device to be activated. The common layer hasverified that the device is not already online.

set_offline: This function is called by the common I/O layer when the device is

de-activated via the ‘online’ attribute. The driver should shutdown the device, but not de-allocate its private data.

int (*set_offline) (struct ccw_device *);

Parameters:

cdev

• the device to be deactivated. The common layer has

  verified that the device is online.

notify:

This function is called by the common I/O layer for some state changesof the device.

Signalled to the driver are:

• In online state, device detached (CIO_GONE) or last path gone(CIO_NO_PATH). The driver must return !0 to keep the device; forreturn code 0, the device will be deleted as usual (also when nonotify function is registered). If the driver wants to keep thedevice, it is moved into disconnected state.
• In disconnected state, device operational again (CIO_OPER). Thecommon I/O layer performs some sanity checks on device number andDevice / CU to be reasonably sure if it is still the same device.If not, the old device is removed and a new one registered. By thereturn code of the notify function the device driver signals if itwants the device back: !0 for keeping, 0 to make the device beingremoved and re-registered.

int (*notify) (struct ccw_device *, int);

Parameters:

cdev

• the device whose state changed.

event

• the event that happened. This can be one of CIO_GONE,CIO_NO_PATH or CIO_OPER.

The handler field of the struct ccw_device is meant to be set to the interrupthandler for the device. In order to accommodate drivers which use severaldistinct handlers (e.g. multi subchannel devices), this is a member of ccw_deviceinstead of ccw_driver.The handler is registered with the common layer during set_online() processingbefore the driver is called, and is deregistered during set_offline() after thedriver has been called. Also, after registering / before deregistering, pathgrouping resp. disbanding of the path group (if applicable) are performed.

void (*handler) (struct ccw_device *dev, unsigned long intparm, struct irb *irb);

Parameters: dev - the device the handler is called for

intparm - the intparm which allows the device driver to identify

the i/o the interrupt is associated with, or to recognizethe interrupt as unsolicited.

irb - interruption response block which contains the accumulated

status.

The device driver is called from the common ccw_device layer and can retrieveinformation about the interrupt from the irb parameter.

1.3 ccwgroup devices¶

The ccwgroup mechanism is designed to handle devices consisting of multiple ccwdevices, like lcs or ctc.

The ccw driver provides a ‘group’ attribute. Piping bus ids of ccw devices tothis attributes creates a ccwgroup device consisting of these ccw devices (ifpossible). This ccwgroup device can be set online or offline just like a normalccw device.

Each ccwgroup device also provides an ‘ungroup’ attribute to destroy the deviceagain (only when offline). This is a generic ccwgroup mechanism (the driver doesnot need to implement anything beyond normal removal routines).

A ccw device which is a member of a ccwgroup device carries a pointer to theccwgroup device in the driver_data of its device struct. This field must not betouched by the driver - it should use the ccwgroup device’s driver_data for itsprivate data.

To implement a ccwgroup driver, please refer to include/asm/ccwgroup.h. Keep inmind that most drivers will need to implement both a ccwgroup and a ccwdriver.

2. Channel paths¶

Channel paths show up, like subchannels, under the channel subsystem root (css0)and are called ‘chp0.<chpid>’. They have no driver and do not belong to any bus.Please note, that unlike /proc/chpids in 2.4, the channel path objects reflectonly the logical state and not the physical state, since we cannot track thelatter consistently due to lacking machine support (we don’t need to be awareof it anyway).

status

• Can be ‘online’ or ‘offline’.Piping ‘on’ or ‘off’ sets the chpid logically online/offline.Piping ‘on’ to an online chpid triggers path reprobing for all devicesthe chpid connects to. This can be used to force the kernel to re-usea channel path the user knows to be online, but the machine hasn’tcreated a machine check for.

type

• The physical type of the channel path.

shared

• Whether the channel path is shared.

cmg

• The channel measurement group.

3. System devices¶

3.1 xpram¶

xpram shows up under devices/system/ as ‘xpram’.

3.2 cpus¶

For each cpu, a directory is created under devices/system/cpu/. Each cpu has anattribute ‘online’ which can be 0 or 1.

4. Other devices¶

4.1 Netiucv¶

The netiucv driver creates an attribute ‘connection’ underbus/iucv/drivers/netiucv. Piping to this attribute creates a new netiucvconnection to the specified host.

Netiucv connections show up under devices/iucv/ as “netiucv<ifnum>”. The interfacenumber is assigned sequentially to the connections defined via the ‘connection’attribute.

user

• shows the connection partner.

buffer

• maximum buffer size. Pipe to it to change buffer size.