PCI: Check BAR index for validity

Many functions in PCI use accessor macros such as pci_resource_len(),
which take a BAR index. That index, however, is never checked for
validity, potentially result

PCI: Check BAR index for validity

Many functions in PCI use accessor macros such as pci_resource_len(),
which take a BAR index. That index, however, is never checked for
validity, potentially resulting in undefined behavior by overflowing the
array pci_dev.resource in the macro pci_resource_n().

Since many users of those macros directly assign the accessed value to
an unsigned integer, the macros cannot be changed easily anymore to
return -EINVAL for invalid indexes. Consequently, the problem has to be
mitigated in higher layers.

Add pci_bar_index_valid(). Use it where appropriate.

Link: https://lore.kernel.org/r/[email protected]
Closes: https://lore.kernel.org/all/[email protected]/
Reported-by: Bingbu Cao <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
[kwilczynski: correct if-statement condition the pci_bar_index_is_valid()
helper function uses, tidy up code comments]
Signed-off-by: Krzysztof Wilczyński <[email protected]>
[bhelgaas: fix typo]
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Fix wrong length of devres array

The array for the iomapping cookie addresses has a length of
PCI_STD_NUM_BARS. This constant, however, only describes standard BARs;
while PCI can allow for add

PCI: Fix wrong length of devres array

The array for the iomapping cookie addresses has a length of
PCI_STD_NUM_BARS. This constant, however, only describes standard BARs;
while PCI can allow for additional, special BARs.

The total number of PCI resources is described by constant
PCI_NUM_RESOURCES, which is also used in, e.g., pci_select_bars().

Thus, the devres array has so far been too small.

Change the length of the devres array to PCI_NUM_RESOURCES.

Link: https://lore.kernel.org/r/[email protected]
Fixes: bbaff68bf4a4 ("PCI: Add managed partial-BAR request and map infrastructure")
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
Cc: [email protected] # v6.11+

show more ...

PCI: Restore original INTX_DISABLE bit by pcim_intx()

pcim_intx() tries to restore the INTx bit at removal via devres, but there
is a chance that it restores a wrong value.

Because the value to be

PCI: Restore original INTX_DISABLE bit by pcim_intx()

pcim_intx() tries to restore the INTx bit at removal via devres, but there
is a chance that it restores a wrong value.

Because the value to be restored is blindly assumed to be the negative of
the enable argument, when a driver calls pcim_intx() unnecessarily for the
already enabled state, it'll restore to the disabled state in turn. That
is, the function assumes the case like:

// INTx == 1
pcim_intx(pdev, 0); // old INTx value assumed to be 1 -> correct

but it might be like the following, too:

// INTx == 0
pcim_intx(pdev, 0); // old INTx value assumed to be 1 -> wrong

Also, when a driver calls pcim_intx() multiple times with different enable
argument values, the last one will win no matter what value it is. This
can lead to inconsistency, e.g.

// INTx == 1
pcim_intx(pdev, 0); // OK
...
pcim_intx(pdev, 1); // now old INTx wrongly assumed to be 0

This patch addresses those inconsistencies by saving the original INTx
state at the first pcim_intx() call. For that, get_or_create_intx_devres()
is folded into pcim_intx() caller side; it allows us to simply check the
already allocated devres and record the original INTx along with the
devres_alloc() call.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 25216afc9db5 ("PCI: Add managed pcim_intx()")
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Philipp Stanner <[email protected]>
Cc: [email protected] # v6.11+

show more ...

PCI: Remove devres from pci_intx()

pci_intx() is a hybrid function which can sometimes be managed through
devres. This hybrid nature is undesirable.

Since all users of pci_intx() have by now been p

PCI: Remove devres from pci_intx()

pci_intx() is a hybrid function which can sometimes be managed through
devres. This hybrid nature is undesirable.

Since all users of pci_intx() have by now been ported either to
always-managed pcim_intx() or never-managed pci_intx_unmanaged(), the
devres functionality can be removed from pci_intx().

Consequently, pci_intx_unmanaged() is now redundant, because pci_intx()
itself is now unmanaged.

Remove the devres functionality from pci_intx(). Have all users of
pci_intx_unmanaged() call pci_intx(). Remove pci_intx_unmanaged().

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Paolo Abeni <[email protected]>

show more ...

PCI: Export pci_intx_unmanaged() and pcim_intx()

pci_intx() is a hybrid function which sometimes performs devres operations,
depending on whether pcim_enable_device() has been used to enable the
pci

PCI: Export pci_intx_unmanaged() and pcim_intx()

pci_intx() is a hybrid function which sometimes performs devres operations,
depending on whether pcim_enable_device() has been used to enable the
pci_dev. This sometimes-managed nature of the function is problematic.
Notably, it causes the function to allocate under some circumstances which
makes it unusable from interrupt context.

Export pcim_intx() (which is always managed) and rename __pcim_intx()
(which is never managed) to pci_intx_unmanaged() and export it as well.

Then all callers of pci_intx() can be ported to the version they need,
depending whether they use pci_enable_device() or pcim_enable_device().

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>

show more ...

PCI: Encourage resource request API users to supply driver name

PCI region request functions have a @name parameter (sometimes called
"res_name"). It is used in a log message to inform drivers about

PCI: Encourage resource request API users to supply driver name

PCI region request functions have a @name parameter (sometimes called
"res_name"). It is used in a log message to inform drivers about request
collisions, e.g., when another driver has requested that region already.

This message is only useful when it contains the actual owner of the
region, i.e., which driver requested it. So far, a great many drivers
misuse the @name parameter and just pass pci_name(), which doesn't result
in useful debug information.

Rename "res_name" to "name".

Detail @name's purpose in the docstrings.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
[bhelgaas: tweak comment wording to include "driver"]
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Deprecate pcim_iounmap_regions()

pcim_ioumap_region() has recently been made a public function and does
not have the disadvantage of having to deal with the legacy iomap table,
as pcim_iounmap_

PCI: Deprecate pcim_iounmap_regions()

pcim_ioumap_region() has recently been made a public function and does
not have the disadvantage of having to deal with the legacy iomap table,
as pcim_iounmap_regions() does.

Deprecate pcim_iounmap_regions().

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Make pcim_iounmap_region() a public function

The function pcim_iounmap_regions() is problematic because it uses a
bitmask mechanism to release / iounmap multiple BARs at once. It, thus,
prevent

PCI: Make pcim_iounmap_region() a public function

The function pcim_iounmap_regions() is problematic because it uses a
bitmask mechanism to release / iounmap multiple BARs at once. It, thus,
prevents getting rid of the problematic iomap table mechanism which was
deprecated in commit e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(),
pcim_iomap_regions_request_all()").

pcim_iounmap_region() does not have that problem. Make it public as the
successor of pcim_iounmap_regions().

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Remove pcim_iomap_regions_request_all()

pcim_iomap_regions_request_all() have been deprecated in
commit e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(),
pcim_iomap_regions_request_all()").

Al

PCI: Remove pcim_iomap_regions_request_all()

pcim_iomap_regions_request_all() have been deprecated in
commit e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(),
pcim_iomap_regions_request_all()").

All users of this function have been ported to other interfaces by now.

Remove pcim_iomap_regions_request_all().

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>

show more ...

PCI: Make pcim_request_all_regions() a public function

In order to remove the deprecated function
pcim_iomap_regions_request_all(), a few drivers need an interface to
request all BARs a PCI device o

PCI: Make pcim_request_all_regions() a public function

In order to remove the deprecated function
pcim_iomap_regions_request_all(), a few drivers need an interface to
request all BARs a PCI device offers.

Make pcim_request_all_regions() a public interface.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>

show more ...

PCI: Fix potential deadlock in pcim_intx()

25216afc9db5 ("PCI: Add managed pcim_intx()") moved the allocation step for
pci_intx()'s device resource from pcim_enable_device() to pcim_intx(). As
befor

PCI: Fix potential deadlock in pcim_intx()

25216afc9db5 ("PCI: Add managed pcim_intx()") moved the allocation step for
pci_intx()'s device resource from pcim_enable_device() to pcim_intx(). As
before, pcim_enable_device() sets pci_dev.is_managed to true; and it is
never set to false again.

Due to the lifecycle of a struct pci_dev, it can happen that a second
driver obtains the same pci_dev after a first driver ran. If one driver
uses pcim_enable_device() and the other doesn't, this causes the other
driver to run into managed pcim_intx(), which will try to allocate when
called for the first time.

Allocations might sleep, so calling pci_intx() while holding spinlocks
becomes then invalid, which causes lockdep warnings and could cause
deadlocks:

========================================================
WARNING: possible irq lock inversion dependency detected
6.11.0-rc6+ #59 Tainted: G W
--------------------------------------------------------
CPU 0/KVM/1537 just changed the state of lock:
ffffa0f0cff965f0 (&vdev->irqlock){-...}-{2:2}, at:
vfio_intx_handler+0x21/0xd0 [vfio_pci_core] but this lock took another,
HARDIRQ-unsafe lock in the past: (fs_reclaim){+.+.}-{0:0}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:

Possible interrupt unsafe locking scenario:

CPU0 CPU1
---- ----
lock(fs_reclaim);
local_irq_disable();
lock(&vdev->irqlock);
lock(fs_reclaim);
<Interrupt>
lock(&vdev->irqlock);

*** DEADLOCK ***

Have pcim_enable_device()'s release function, pcim_disable_device(), set
pci_dev.is_managed to false so that subsequent drivers using the same
struct pci_dev do not implicitly run into managed code.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 25216afc9db5 ("PCI: Add managed pcim_intx()")
Reported-by: Alex Williamson <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Suggested-by: Alex Williamson <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Alex Williamson <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>

show more ...

PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()

pcim_iomap_regions() is a complicated function that uses a bit mask to
determine the BARs the user wishes to request and ioremap.

PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()

pcim_iomap_regions() is a complicated function that uses a bit mask to
determine the BARs the user wishes to request and ioremap. Almost all users
only ever set a single bit in that mask, making that mechanism
questionable.

pcim_iomap_region() is now available as a more simple replacement.

Make pcim_iomap_region() a public function.

Mark pcim_iomap_regions() as deprecated.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Make pcim_request_region() a public function

pcim_request_region() is the managed counterpart of pci_request_region().
It is currently only used internally for PCI.

It can be useful for a numb

PCI: Make pcim_request_region() a public function

pcim_request_region() is the managed counterpart of pci_request_region().
It is currently only used internally for PCI.

It can be useful for a number of drivers and exporting it is a step towards
deprecating more complicated functions.

Make pcim_request_region() a public function.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Hans de Goede <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Acked-by: Hans de Goede <[email protected]>

show more ...

PCI: Add managed pcim_iomap_range()

The only managed mapping function currently is pcim_iomap() which doesn't
allow for mapping an area starting at a certain offset, which many drivers
want.

Add pc

PCI: Add managed pcim_iomap_range()

The only managed mapping function currently is pcim_iomap() which doesn't
allow for mapping an area starting at a certain offset, which many drivers
want.

Add pcim_iomap_range() as an exported function.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Remove legacy pcim_release()

Thanks to preceding cleanup steps, pcim_release() is now not needed
anymore and can be replaced by pcim_disable_device(), which is the exact
counterpart to pcim_ena

PCI: Remove legacy pcim_release()

Thanks to preceding cleanup steps, pcim_release() is now not needed
anymore and can be replaced by pcim_disable_device(), which is the exact
counterpart to pcim_enable_device().

This permits removing further parts of the old PCI devres implementation.

Replace pcim_release() with pcim_disable_device(). Remove the now unused
function get_pci_dr(). Remove the struct pci_devres from pci.h.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Add managed pcim_intx()

pci_intx() is a "hybrid" function, i.e., it is managed if
pcim_enable_device() has been called, but unmanaged otherwise.

Add pcim_intx(), which is always managed, and i

PCI: Add managed pcim_intx()

pci_intx() is a "hybrid" function, i.e., it is managed if
pcim_enable_device() has been called, but unmanaged otherwise.

Add pcim_intx(), which is always managed, and implement pci_intx() using
it.

Remove the now-unused struct pci_devres.orig_intx and .restore_intx and
find_pci_dr().

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
[kwilczynski: squashed in
https://lore.kernel.org/r/[email protected]
to fix problem reported and tested by Ashish Kalra <[email protected]>:
https://lore.kernel.org/r/[email protected]
https://lore.kernel.org/r/[email protected]/]
Signed-off-by: Krzysztof Wilczyński <[email protected]>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Give pcim_set_mwi() its own devres cleanup callback

Managing pci_set_mwi() with devres can easily be done with its own
callback, without the necessity to store any state about it in a
device-re

PCI: Give pcim_set_mwi() its own devres cleanup callback

Managing pci_set_mwi() with devres can easily be done with its own
callback, without the necessity to store any state about it in a
device-related struct.

Remove the MWI state from struct pci_devres. Give pcim_set_mwi() a
separate devres cleanup callback.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Move struct pci_devres.pinned bit to struct pci_dev

The bit describing whether the PCI device is currently pinned is stored
in struct pci_devres. To clean up and simplify the PCI devres API, it

PCI: Move struct pci_devres.pinned bit to struct pci_dev

The bit describing whether the PCI device is currently pinned is stored
in struct pci_devres. To clean up and simplify the PCI devres API, it's
better if this information is stored in struct pci_dev.

This will later permit simplifying pcim_enable_device().

Move the 'pinned' boolean bit to struct pci_dev.

Restructure bits in struct pci_dev so the pm / pme fields are next to
each other.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Remove struct pci_devres.enabled status bit

The struct pci_devres has a separate boolean to track whether a device is
enabled. That, however, can easily be tracked in an agnostic manner through

PCI: Remove struct pci_devres.enabled status bit

The struct pci_devres has a separate boolean to track whether a device is
enabled. That, however, can easily be tracked in an agnostic manner through
the function pci_is_enabled().

Using it allows for simplifying the PCI devres implementation.

Replace the separate 'enabled' status bit from struct pci_devres with
calls to pci_is_enabled() at the appropriate places.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Add managed pcim_request_region()

These existing functions:

pci_request_region()
pci_request_selected_regions()
pci_request_selected_regions_exclusive()

are "hybrid" functions built on

PCI: Add managed pcim_request_region()

These existing functions:

pci_request_region()
pci_request_selected_regions()
pci_request_selected_regions_exclusive()

are "hybrid" functions built on __pci_request_region() and are managed if
pcim_enable_device() has been called, but unmanaged otherwise.

Add these new functions:

pcim_request_region()
pcim_request_region_exclusive()

These are *always* managed and use the new pcim_addr_devres tracking
infrastructure instead of find_pci_dr() and struct pci_devres.region_mask.

Implement the hybrid functions using the new "pure" functions and remove
struct pci_devres.region_mask, which is no longer needed.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()

Deprecate pcim_iomap_table(). It returns a pointer to a table of
ioremapped BARs, or NULL if it fails. This makes uses like this

PCI: Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()

Deprecate pcim_iomap_table(). It returns a pointer to a table of
ioremapped BARs, or NULL if it fails. This makes uses like this:

addr = pcim_iomap_table(pdev)[0];

problematic because it causes a NULL pointer dereference on failure.
Callers should use pcim_iomap() instead.

Deprecate pcim_iomap_regions_request_all() because it is built on
__pci_request_region() and is managed if pcim_enable_device() has been
called, but unmanaged otherwise, which is prone to errors.

Callers should either use pcim_iomap_regions() to request and map BARs, or
use pcim_request_region() followed by pcim_iomap().

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
[bhelgaas: commit log, sphinx markup]
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Add managed partial-BAR request and map infrastructure

The pcim_iomap_devres table tracks entire-BAR mappings, so we can't use it
to build a managed version of pci_iomap_range(), which maps par

PCI: Add managed partial-BAR request and map infrastructure

The pcim_iomap_devres table tracks entire-BAR mappings, so we can't use it
to build a managed version of pci_iomap_range(), which maps partial BARs.

Add struct pcim_addr_devres, which can track request and mapping of both
entire BARs and partial BARs.

Add the following internal devres functions based on struct
pcim_addr_devres:

pcim_iomap_region() # request & map entire BAR
pcim_iounmap_region() # unmap & release entire BAR
pcim_request_region() # request entire BAR
pcim_release_region() # release entire BAR
pcim_request_all_regions() # request all entire BARs
pcim_release_all_regions() # release all entire BARs

Rework the following public interfaces using the new infrastructure
listed above:

pcim_iomap() # map partial BAR
pcim_iounmap() # unmap partial BAR
pcim_iomap_regions() # request & map specified BARs
pcim_iomap_regions_request_all() # request all BARs, map specified BARs
pcim_iounmap_regions() # unmap & release specified BARs

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Add devres helpers for iomap table

The pcim_iomap_devres.table administrated by pcim_iomap_table() has its
entries set and unset at several places throughout devres.c using manual
iterations wh

PCI: Add devres helpers for iomap table

The pcim_iomap_devres.table administrated by pcim_iomap_table() has its
entries set and unset at several places throughout devres.c using manual
iterations which are effectively code duplications.

Add pcim_add_mapping_to_legacy_table() and
pcim_remove_mapping_from_legacy_table() helper functions and use them where
possible.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Add and use devres helper for bit masks

The current devres implementation uses manual shift operations to check
whether a bit in a mask is set. The code can be made more readable by
writing a s

PCI: Add and use devres helper for bit masks

The current devres implementation uses manual shift operations to check
whether a bit in a mask is set. The code can be made more readable by
writing a small helper function for that.

Implement mask_contains_bar() and use it where applicable.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Move devres code from pci.c to devres.c

The file pci.c is very large and contains a number of devres functions.
These functions should now reside in devres.c.

Move as much devres-specific code

PCI: Move devres code from pci.c to devres.c

The file pci.c is very large and contains a number of devres functions.
These functions should now reside in devres.c.

Move as much devres-specific code from pci.c to devres.c as possible.

There are a few callers left in pci.c that do devres operations. These
should be ported in the future. Add corresponding TODOs.

The reason they are not moved right now in this commit is that PCI's devres
currently implements a sort of "hybrid-mode": pci_request_region(), for
instance, does not have a corresponding pcim_ equivalent, yet. Instead, the
function can be made managed by previously calling pcim_enable_device()
(instead of pci_enable_device()). This makes it unreasonable to move
pci_request_region() to devres.c. Moving the functions would require
changes to PCI's API and is, therefore, left for future work.

In summary, this commit serves as a preparation step for a following
patch series that will cleanly separate the PCI's managed and unmanaged
API.

Link: https://lore.kernel.org/r/[email protected]
Suggested-by: Danilo Krummrich <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...