driver core: have match() callback in struct bus_type take a const *

In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *. This

driver core: have match() callback in struct bus_type take a const *

In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *. This is one
step of many towards making the driver core safe to have struct
device_driver in read-only memory.

Because the match() callback is in all busses, all busses are modified
to handle this properly. This does entail switching some container_of()
calls to container_of_const() to properly handle the constant *.

For some busses, like PCI and USB and HV, the const * is cast away in
the match callback as those busses do want to modify those structures at
this point in time (they have a local lock in the driver structure.)
That will have to be changed in the future if they wish to have their
struct device * in read-only-memory.

Cc: Rafael J. Wysocki <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Acked-by: Sumit Garg <[email protected]>
Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

s390/virtio_ccw: use DMA handle from DMA API

Change and use ccw_device_dma_zalloc() so it returns a virtual address like
before, which can be used to access data. However also pass a new dma32_t
poi

s390/virtio_ccw: use DMA handle from DMA API

Change and use ccw_device_dma_zalloc() so it returns a virtual address like
before, which can be used to access data. However also pass a new dma32_t
pointer type handle, which correlates to the returned virtual address.
This pointer is used to directly pass/set the DMA handle as returned by the
DMA API.

Signed-off-by: Halil Pasic <[email protected]>
Reviewed-by: Eric Farman <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>

show more ...

s390/cio: introduce locking for register/unregister functions

Unbinding an I/O subchannel with a child-CCW device in disconnected
state sometimes causes a kernel-panic. The race condition was seen
m

s390/cio: introduce locking for register/unregister functions

Unbinding an I/O subchannel with a child-CCW device in disconnected
state sometimes causes a kernel-panic. The race condition was seen
mostly during testing, when setting all the CHPIDs of a device to
offline and at the same time, the unbinding the I/O subchannel driver.

The kernel-panic occurs because of double delete, the I/O subchannel
driver calls device_del on the CCW device while another device_del
invocation for the same device is in-flight. For instance, disabling
all the CHPIDs will trigger the ccw_device_remove function, which will
call a ccw_device_unregister(), which ends up calling the device_del()
which is asynchronous via cdev's todo workqueue. And unbinding the I/O
subchannel driver calls io_subchannel_remove() function which calls the
ccw_device_unregister() and device_del().

This double delete can be prevented by serializing all CCW device
registration/unregistration calls into the driver core. This patch
introduces a mutex which will be used for this purpose.

Signed-off-by: Vineeth Vijayan <[email protected]>
Reported-by: Boris Fiuczynski <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>

show more ...

s390/cio: remove unused ccw_device_force_console() declaration

ccw_device_force_console() has been removed by
commit 8cc0dcfdc1c0 ("s390/cio: remove pm support from
ccw bus driver"), so remove the d

s390/cio: remove unused ccw_device_force_console() declaration

ccw_device_force_console() has been removed by
commit 8cc0dcfdc1c0 ("s390/cio: remove pm support from
ccw bus driver"), so remove the declaration, too.

Signed-off-by: Gaosheng Cui <[email protected]>
Acked-by: Vineeth Vijayan <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>

show more ...

s390/cio: remove duplicate struct ccw1 declaration

struct ccw1 is declared twice. One has been declared
at 21st line. Remove the duplicate.

Signed-off-by: Wan Jiabing <[email protected]>
Acked-by

s390/cio: remove duplicate struct ccw1 declaration

struct ccw1 is declared twice. One has been declared
at 21st line. Remove the duplicate.

Signed-off-by: Wan Jiabing <[email protected]>
Acked-by: Vineeth Vijayan <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>

show more ...

s390/cio: remove pm support from ccw bus driver

As part of removing broken pm-support from s390 arch, remove
the pm callbacks from ccw-bus driver.The power-management functions
are unused since the

s390/cio: remove pm support from ccw bus driver

As part of removing broken pm-support from s390 arch, remove
the pm callbacks from ccw-bus driver.The power-management functions
are unused since the 'commit 394216275c7d ("s390: remove broken
hibernate / power management support")'.

Signed-off-by: Vineeth Vijayan <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>

show more ...

s390/cio: fix kernel-doc markups in cio driver.

Fix typo in the kernel-doc markups
1. ccw driver -> ccw_driver
2. ccw_device_id_is_equal() -> ccw_dev_id_is_equal

Signed-off-by: Mauro Carvalho Che

s390/cio: fix kernel-doc markups in cio driver.

Fix typo in the kernel-doc markups
1. ccw driver -> ccw_driver
2. ccw_device_id_is_equal() -> ccw_dev_id_is_equal

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Reviewed-by: Cornelia Huck <[email protected]>
[[email protected]: slight modification in the changelog]
Reviewed-by: Vineeth Vijayan <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>

show more ...

s390/cio: Add support for FCES status notification

Fibre Channel Endpoint-Security event is received as an sei:nt0 type
in the CIO layer. This information needs to be shared with the
CCW device driv

s390/cio: Add support for FCES status notification

Fibre Channel Endpoint-Security event is received as an sei:nt0 type
in the CIO layer. This information needs to be shared with the
CCW device drivers using the path_events callback.

Co-developed-by: Sebastian Ott <[email protected]>
Signed-off-by: Vineeth Vijayan <[email protected]>
Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Stefan Haberland <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Acked-by: Vasily Gorbik <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>

show more ...

s390/cio: Helper functions to read CSSID, IID, and CHID

Add helper functions to expose Channel Subsystem ID (CSSID), MIF Image Id
(IID), Channel ID (CHID) and Channel Path ID (CHPID).
These values a

s390/cio: Helper functions to read CSSID, IID, and CHID

Add helper functions to expose Channel Subsystem ID (CSSID), MIF Image Id
(IID), Channel ID (CHID) and Channel Path ID (CHPID).
These values are required by the qeth driver's exploitation of network-
address-change-notifications to determine which entries belong to this
interface.

Store the Partition identifier in System log, as this may be used to map
a Linux view to a Hardware view for debugging purpose.

Signed-off-by: Alexandra Winter <[email protected]>
Reviewed-by: Vineeth Vijayan <[email protected]>
Signed-off-by: Julian Wiedmann <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

s390/cio: Add new Operation Code OC3 to PNSO

Add support for operation code 3 (OC3) of the
Perform-Network-Subchannel-Operations (PNSO) function
of the Channel-Subsystem-Call (CHSC) instruction.

PN

s390/cio: Add new Operation Code OC3 to PNSO

Add support for operation code 3 (OC3) of the
Perform-Network-Subchannel-Operations (PNSO) function
of the Channel-Subsystem-Call (CHSC) instruction.

PNSO provides 2 operation codes:
OC0 - BRIDGE_INFO
OC3 - ADDR_INFO (new)

Extend the function calls to *pnso* to pass the OC and
add new response code 0108.

Support for OC3 is indicated by a flag in the css_general_characteristics.

Signed-off-by: Alexandra Winter <[email protected]>
Reviewed-by: Julian Wiedmann <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Reviewed-by: Vineeth Vijayan <[email protected]>
Signed-off-by: Julian Wiedmann <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

s390/cio, s390/qeth: cleanup PNSO CHSC

CHSC3D (PNSO - perform network subchannel operation) is used for
OC0 (Store-network-bridging-information) as well as for
OC3 (Store-network-address-information

s390/cio, s390/qeth: cleanup PNSO CHSC

CHSC3D (PNSO - perform network subchannel operation) is used for
OC0 (Store-network-bridging-information) as well as for
OC3 (Store-network-address-information). So common fields are renamed
from *brinfo* to *pnso*.
Also *_bridge_host_* is changed into *_addr_change_*, e.g.
qeth_bridge_host_event to qeth_addr_change_event, for the
same reasons.
The keywords in the card traces are changed accordingly.

Remove unused L3 types, as PNSO will only return Layer2 entries.

Make PNSO CHSC implementation more consistent with existing API usage:
Add new function ccw_device_pnso() to drivers/s390/cio/device_ops.c and
the function declaration to arch/s390/include/asm/ccwdev.h, which takes
a struct ccw_device * as parameter instead of schid and calls
chsc_pnso().

PNSO CHSC has no strict relationship to qdio. So move the calling
function from qdio to qeth_l2 and move the necessary structures to a
new file arch/s390/include/asm/chsc.h.

Do response code evaluation only in chsc_error_from_response() and
use return code in all other places. qeth_anset_makerc() was meant to
evaluate the PNSO response code, but never did, because pnso_rc was
already non-zero.

Indentation was corrected in some places.

Signed-off-by: Alexandra Winter <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Reviewed-by: Vineeth Vijayan <[email protected]>
Reviewed-by: Julian Wiedmann <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>

show more ...

s390/cio: add basic protected virtualization support

As virtio-ccw devices are channel devices, we need to use the
dma area within the common I/O layer for any communication with
the hypervisor.

No

s390/cio: add basic protected virtualization support

As virtio-ccw devices are channel devices, we need to use the
dma area within the common I/O layer for any communication with
the hypervisor.

Note that we do not need to use that area for control blocks
directly referenced by instructions, e.g. the orb.

It handles neither QDIO in the common code, nor any device type specific
stuff (like channel programs constructed by the DASD driver).

An interesting side effect is that virtio structures are now going to
get allocated in 31 bit addressable storage.

Signed-off-by: Halil Pasic <[email protected]>
Reviewed-by: Sebastian Ott <[email protected]>
Reviewed-by: Cornelia Huck <[email protected]>
Reviewed-by: Michael Mueller <[email protected]>
Tested-by: Michael Mueller <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>

show more ...

s390/cio: add helper to query utility strings per given ccw device

Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

s390/cio: rename struct channel_path_desc

Rename struct channel_path_desc to struct channel_path_desc_fmt0
to fit the scheme. Provide a macro for the function wrappers that
gather this and related d

s390/cio: rename struct channel_path_desc

Rename struct channel_path_desc to struct channel_path_desc_fmt0
to fit the scheme. Provide a macro for the function wrappers that
gather this and related data from firmware.

Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

s390/cio: fix multiple structure definitions

Fix multiple definitions of struct channel_path_desc by moving it
to asm/chpid.h . Also change ccw_device_get_chp_desc to use proper
types.

Reviewed-by:

s390/cio: fix multiple structure definitions

Fix multiple definitions of struct channel_path_desc by moving it
to asm/chpid.h . Also change ccw_device_get_chp_desc to use proper
types.

Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/cio: reorder initialization of ccw consoles

Drivers for ccw consoles use ccw_device_probe_console to receive
an initialized ccw device which is already enabled for interrupts.
After that the de

s390/cio: reorder initialization of ccw consoles

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 <[email protected]>
Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/cio: fix driver callback initialization for ccw consoles

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

s390/cio: fix driver callback initialization for ccw consoles

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: <[email protected]> # 3.10+
Reported-by: Mike Frysinger <[email protected]>
Reported-by: Heiko Carstens <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/cio: ccw_device_force_console don't use static variable

force_console is used to wake up the CCW based console device to
print a panic message in case something goes wrong in a suspend
or resum

s390/cio: ccw_device_force_console don't use static variable

force_console is used to wake up the CCW based console device to
print a panic message in case something goes wrong in a suspend
or resume cycle. Stop using the static console_subchannel and add
a parameter to this function to specify which ccw device we have
to wake up.

Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/cio: wait_cons_dev don't use static variable

wait_cons_dev is used to busy wait for an interrupt on the console
ccw device. Stop using the static console_subchannel and add a
parameter to this

s390/cio: wait_cons_dev don't use static variable

wait_cons_dev is used to busy wait for an interrupt on the console
ccw device. Stop using the static console_subchannel and add a
parameter to this function to specify on which ccw device/subchannel
we have to do the polling.

While at it rename the function to ccw_device_wait_idle and
move it to device.c

Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/ccwdev: Include asm/schid.h.

Get the definition of struct subchannel_id.

Reviewed-by: Alexander Graf <[email protected]>
Signed-off-by: Cornelia Huck <[email protected]>
Signed-off-by: Gleb

s390/ccwdev: Include asm/schid.h.

Get the definition of struct subchannel_id.

Reviewed-by: Alexander Graf <[email protected]>
Signed-off-by: Cornelia Huck <[email protected]>
Signed-off-by: Gleb Natapov <[email protected]>

show more ...

s390/ccwdev: Include asm/schid.h.

Get the definition of struct subchannel_id.

Signed-off-by: Cornelia Huck <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

s390: use ccw_device_get_schid

Let the dasd driver and qdio use ccw_device_get_schid and
get rid of other similar functions.

Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by:

s390: use ccw_device_get_schid

Let the dasd driver and qdio use ccw_device_get_schid and
get rid of other similar functions.

Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390: Add a mechanism to get the subchannel id.

This will be needed by the new virtio-ccw transport.

Signed-off-by: Cornelia Huck <[email protected]>
Signed-off-by: Martin Schwidefsky <schwi

s390: Add a mechanism to get the subchannel id.

This will be needed by the new virtio-ccw transport.

Signed-off-by: Cornelia Huck <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/comments: unify copyright messages and remove file names

Remove the file name from the comment at top of many files. In most
cases the file name was wrong anyway, so it's rather pointless.

Als

s390/comments: unify copyright messages and remove file names

Remove the file name from the comment at top of many files. In most
cases the file name was wrong anyway, so it's rather pointless.

Also unify the IBM copyright statement. We did have a lot of sightly
different statements and wanted to change them one after another
whenever a file gets touched. However that never happened. Instead
people start to take the old/"wrong" statements to use as a template
for new files.
So unify all of them in one go.

Signed-off-by: Heiko Carstens <[email protected]>

show more ...