kernel/linux.git/drivers/s390/cio/device.c, branch linux-4.4.y

s390/cio: avoid duplicated 'ADD' uevents

2020-05-02T15:20:31+00:00

[ Upstream commit 05ce3e53f375295c2940390b2b429e506e07655c ] The common I/O layer delays the ADD uevent for subchannels and delegates generating this uevent to the individual subchannel drivers. The io_subchannel driver will do so when the associated ccw_device has been registered -- but unconditionally, so more ADD uevents will be generated if a subchannel has been unbound from the io_subchannel driver and later rebound. To fix this, only generate the ADD event if uevents were still suppressed for the device. Fixes: fa1a8c23eb7d ("s390: cio: Delay uevents for subchannels") Message-Id: <20200327124503.9794-2-cohuck@redhat.com> Reported-by: Boris Fiuczynski Reviewed-by: Peter Oberparleiter Reviewed-by: Boris Fiuczynski Signed-off-by: Cornelia Huck Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

s390/cio: fix use after free in cmb processing

2015-10-14T12:32:02+00:00

Devices with active channel measurement are included in a list. When a device is removed without deactivating channel measurement first the list_head is freed but still used. Fix this by making sure that channel measurement is deactivated during device deregistration. For devices that we deregister because they are no longer accessible deactivating channel measurement will fail. In this case we can report success because the FW will no longer access the measurement block. In addition to these steps keep an extra device reference while channel measurement is active. Signed-off-by: Sebastian Ott Reviewed-by: Cornelia Huck Signed-off-by: Martin Schwidefsky

s390/cio: use device_lock during cmb activation

2015-10-14T12:32:02+00:00

Hold the device_lock during [de]activation of the channel measurement block to synchronize concurrent usage of these functions. Signed-off-by: Sebastian Ott Reviewed-by: Martin Schwidefsky Signed-off-by: Martin Schwidefsky

s390/cio: set device name as early as possible

2014-06-16T08:31:03+00:00

Currently we set the device name at the time we call device_add after we receive the interrupt for the first I/O. When something is not working as expected during that first I/O (e.g. we don't receive an interrupt) we print a message including the device name which has not yet been initialized. Set the device name after calling device_initialize (prior to starting the first I/O) so that we have the name present if some unexpected error occurs during that first I/O. Reported-by: Cornelia Huck Reported-by: Jason J. Herne Reviewed-by: Peter Oberparleiter Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky

s390/cio: fix irq stats for early interrupts on ccw consoles

2014-02-21T07:50:13+00:00

Interrupts which happen on ccw consoles prior to their registration with the driver core are not accounted to the respective device driver. Fix this by setting the proper interrupt class during initialization of ccw consoles. Reviewed-by: Peter Oberparleiter Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky

s390/cio: reorder initialization of ccw consoles

2014-02-21T07:50:12+00:00

Drivers for ccw consoles use ccw_device_probe_console to receive an initialized ccw device which is already enabled for interrupts. After that the device driver does the initialization of its private data. This can race with unsolicited interrupts which can happen once the device is enabled for interrupts. Split ccw_device_probe_console into ccw_device_create_console and ccw_device_enable_console and reorder the initialization of the ccw console drivers. While at it mark these functions as __init. Reviewed-by: Peter Oberparleiter Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky

s390/cio: fix driver callback initialization for ccw consoles

2014-02-21T07:50:11+00:00

ccw consoles are in use before they can be properly registered with the driver core. For devices which are in use by a device driver we rely on the ccw_device's pointer to the driver callbacks to be valid. For ccw consoles this pointer is NULL until they are registered later during boot and we dereferenced this pointer. This worked by chance on 64 bit builds (cdev->drv was NULL but the optional callback cdev->drv->path_event was also NULL by coincidence) and was unnoticed until we received reports about boot failures on 31 bit systems. Fix it by initializing the driver pointer for ccw consoles. Cc: # 3.10+ Reported-by: Mike Frysinger Reported-by: Heiko Carstens Reviewed-by: Peter Oberparleiter Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky

s390/cio: use device_lock to synchronize calls to the ccw driver

2013-12-16T13:38:02+00:00

When calling set_{on,off}line of a ccw device driver we hold the module reference of the owner. This is pretty useless - we don't want to prevent module unloading but driver unbinding. Use the driver core's device_lock instead. Reviewed-by: Peter Oberparleiter Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky

s390/cio: fix unlocked access of online member

2013-12-16T13:38:01+00:00

Make sure that access to the online member of a ccw device is guarded by the ccwlock. Reported-by: Cornelia Huck Reviewed-by: Peter Oberparleiter Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky

s390: replace strict_strtoul() with kstrtoul()

2013-08-22T10:20:00+00:00

The usage of strict_strtoul() is not preferred, because strict_strtoul() is obsolete. Thus, kstrtoul() should be used. Signed-off-by: Jingoo Han Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky