fwctl: Add basic structure for a class subsystem with a cdev

Create the class, character device and functions for a fwctl driver to
un/register to the subsystem.

A typical fwctl driver has a sysfs

fwctl: Add basic structure for a class subsystem with a cdev

Create the class, character device and functions for a fwctl driver to
un/register to the subsystem.

A typical fwctl driver has a sysfs presence like:

$ ls -l /dev/fwctl/fwctl0
crw------- 1 root root 250, 0 Apr 25 19:16 /dev/fwctl/fwctl0

$ ls /sys/class/fwctl/fwctl0
dev device power subsystem uevent

$ ls /sys/class/fwctl/fwctl0/device/infiniband/
ibp0s10f0

$ ls /sys/class/infiniband/ibp0s10f0/device/fwctl/
fwctl0/

$ ls /sys/devices/pci0000:00/0000:00:0a.0/fwctl/fwctl0
dev device power subsystem uevent

Which allows userspace to link all the multi-subsystem driver components
together and learn the subsystem specific names for the device's
components.

Link: https://patch.msgid.link/r/[email protected]
Reviewed-by: Jonathan Cameron <[email protected]>
Reviewed-by: Dan Williams <[email protected]>
Reviewed-by: Dave Jiang <[email protected]>
Reviewed-by: Shannon Nelson <[email protected]>
Tested-by: Dave Jiang <[email protected]>
Tested-by: Shannon Nelson <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>

show more ...

vlynq: remove bus driver

There are no users with a vlynq_driver in the Kernel tree. Also, only
the AR7 platform ever initialized a VLYNQ bus, but AR7 is going to be
removed from the Kernel. OpenWRT

vlynq: remove bus driver

There are no users with a vlynq_driver in the Kernel tree. Also, only
the AR7 platform ever initialized a VLYNQ bus, but AR7 is going to be
removed from the Kernel. OpenWRT had some out-of-tree drivers which they
probably intended to upport, but AR7 devices are even there not
supported anymore because they are "stuck with Kernel
3.18" [1]. This code can go.

[1] https://openwrt.org/docs/techref/targets/ar7

Signed-off-by: Wolfram Sang <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
Signed-off-by: Thomas Bogendoerfer <[email protected]>

show more ...

pmdomain: Prepare to move Kconfig files into the pmdomain subsystem

Rather than having the various Kconfig files for the genpd providers
sprinkled across subsystems, let's prepare to move them into

pmdomain: Prepare to move Kconfig files into the pmdomain subsystem

Rather than having the various Kconfig files for the genpd providers
sprinkled across subsystems, let's prepare to move them into the pmdomain
subsystem along with the implementations.

Reviewed-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>

show more ...

dpll: core: Add DPLL framework base functions

DPLL framework is used to represent and configure DPLL devices
in systems. Each device that has DPLL and can configure inputs
and outputs can use this f

dpll: core: Add DPLL framework base functions

DPLL framework is used to represent and configure DPLL devices
in systems. Each device that has DPLL and can configure inputs
and outputs can use this framework.

Implement core framework functions for further interactions
with device drivers implementing dpll subsystem, as well as for
interactions of DPLL netlink framework part with the subsystem
itself.

Co-developed-by: Milena Olech <[email protected]>
Signed-off-by: Milena Olech <[email protected]>
Co-developed-by: Michal Michalik <[email protected]>
Signed-off-by: Michal Michalik <[email protected]>
Signed-off-by: Vadim Fedorenko <[email protected]>
Co-developed-by: Arkadiusz Kubalewski <[email protected]>
Signed-off-by: Arkadiusz Kubalewski <[email protected]>
Signed-off-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

cache: Add L2 cache management for Andes AX45MP RISC-V core

I/O Coherence Port (IOCP) provides an AXI interface for connecting
external non-caching masters, such as DMA controllers. The accesses
fro

cache: Add L2 cache management for Andes AX45MP RISC-V core

I/O Coherence Port (IOCP) provides an AXI interface for connecting
external non-caching masters, such as DMA controllers. The accesses
from IOCP are coherent with D-Caches and L2 Cache.

IOCP is a specification option and is disabled on the Renesas RZ/Five
SoC due to this reason IP blocks using DMA will fail.

The Andes AX45MP core has a Programmable Physical Memory Attributes (PMA)
block that allows dynamic adjustment of memory attributes in the runtime.
It contains a configurable amount of PMA entries implemented as CSR
registers to control the attributes of memory locations in interest.
Below are the memory attributes supported:
* Device, Non-bufferable
* Device, bufferable
* Memory, Non-cacheable, Non-bufferable
* Memory, Non-cacheable, Bufferable
* Memory, Write-back, No-allocate
* Memory, Write-back, Read-allocate
* Memory, Write-back, Write-allocate
* Memory, Write-back, Read and Write-allocate

More info about PMA (section 10.3):
Link: http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf

As a workaround for SoCs with IOCP disabled CMO needs to be handled by
software. Firstly OpenSBI configures the memory region as
"Memory, Non-cacheable, Bufferable" and passes this region as a global
shared dma pool as a DT node. With DMA_GLOBAL_POOL enabled all DMA
allocations happen from this region and synchronization callbacks are
implemented to synchronize when doing DMA transactions.

Example PMA region passes as a DT node from OpenSBI:
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;

pma_resv0@58000000 {
compatible = "shared-dma-pool";
reg = <0x0 0x58000000 0x0 0x08000000>;
no-map;
linux,dma-default;
};
};

Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
Tested-by: Conor Dooley <[email protected]> # tyre-kicking on a d1
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>

show more ...

video: Add auxiliary display drivers to Graphics support menu

The drivers in this subsystem are for either character-based or monochrome
LCD controllers. Which can fall into the same category of the

video: Add auxiliary display drivers to Graphics support menu

The drivers in this subsystem are for either character-based or monochrome
LCD controllers. Which can fall into the same category of the DRM/KMS and
fbdev drivers, that are located under the "Graphics support" menu.

Add the auxdisplay drivers there as well to have all display drivers under
the same menu.

Suggested-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Tested-by: Arnd Bergmann <[email protected]>
Acked-by: Helge Deller <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

cdx: add the cdx bus driver

Introduce AMD CDX bus, which provides a mechanism for scanning
and probing CDX devices. These devices are memory mapped on
system bus for Application Processors(APUs).

C

cdx: add the cdx bus driver

Introduce AMD CDX bus, which provides a mechanism for scanning
and probing CDX devices. These devices are memory mapped on
system bus for Application Processors(APUs).

CDX devices can be changed dynamically in the Fabric and CDX
bus interacts with CDX controller to rescan the bus and
rediscover the devices.

Signed-off-by: Nipun Gupta <[email protected]>
Reviewed-by: Pieter Jansen van Vuuren <[email protected]>
Tested-by: Nikhil Agarwal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers/accel: define kconfig and register a new major

Add a new Kconfig for the accel subsystem. The Kconfig currently
contains only the basic CONFIG_DRM_ACCEL option that will be used to
decide wh

drivers/accel: define kconfig and register a new major

Add a new Kconfig for the accel subsystem. The Kconfig currently
contains only the basic CONFIG_DRM_ACCEL option that will be used to
decide whether to compile the accel registration code. Therefore, the
kconfig option is defined as bool.

The accel code will be compiled as part of drm.ko and will be called
directly from the DRM core code. The reason we compile it as part of
drm.ko and not as a separate module is because of cyclic dependency
between drm.ko and the separate module (if it would have existed).
This is due to the fact that DRM core code calls accel functions and
vice-versa.

The accelerator devices will be exposed to the user space with a new,
dedicated major number - 261.

The accel init function registers the new major number as a char device
and create corresponding sysfs and debugfs root entries, similar to
what is done in DRM init function.

I added a new header called drm_accel.h to include/drm/, that will hold
the prototypes of the drm_accel.c functions. In case CONFIG_DRM_ACCEL
is set to 'N', that header will contain empty inline implementations of
those functions, to allow DRM core code to compile successfully
without dependency on CONFIG_DRM_ACCEL.

I Updated the MAINTAINERS file accordingly with the newly added folder
and I have taken the liberty to appropriate the dri-devel mailing list
and the dri-devel IRC channel for the accel subsystem.

Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Acked-by: Jacek Lawrynowicz <[email protected]>
Tested-by: Jacek Lawrynowicz <[email protected]>
Reviewed-by: Melissa Wen <[email protected]>

show more ...

vme: move back to staging

The VME subsystem graduated from staging into a top-level subsystem in
2012, with commit db3b9e990e75 ("Staging: VME: move VME drivers out of
staging") stating:

The VM

vme: move back to staging

The VME subsystem graduated from staging into a top-level subsystem in
2012, with commit db3b9e990e75 ("Staging: VME: move VME drivers out of
staging") stating:

The VME device drivers have not moved out yet due to some API
questions they are still working through, that should happen soon,
hopefully.

However, this never happened: maintenance of drivers/vme effectively
stopped in 2017, with all subsequent changes being treewide cleanups.
No hardware driver remains in staging, only the limited user-level
access, and I just removed one of the two bridge drivers and the only
remaining board.

drivers/staging/vme/devices/ was recently moved to
drivers/staging/vme_user/, but as the vme_user driver is the only one
remaining for this subsystem, it is easier to just move the remaining
three source files into this directory rather than keeping the original
hierarchy.

Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

scsi: ufs: Split the drivers/scsi/ufs directory

Split the drivers/scsi/ufs directory into 'core' and 'host' directories
under the drivers/ufs/ directory. Move shared header files into the
include/uf

scsi: ufs: Split the drivers/scsi/ufs directory

Split the drivers/scsi/ufs directory into 'core' and 'host' directories
under the drivers/ufs/ directory. Move shared header files into the
include/ufs/ directory. This separation makes it clear which header files
UFS drivers are allowed to include (include/ufs/*.h) and which header files
UFS drivers are not allowed to include (drivers/ufs/core/*.h).

Update the MAINTAINERS file. Add myself as a UFS reviewer.

Link: https://lore.kernel.org/r/[email protected]
Cc: Adrian Hunter <[email protected]>
Cc: Avri Altman <[email protected]>
Cc: Bean Huo <[email protected]>
Cc: Bjorn Andersson <[email protected]>
Cc: Keoseong Park <[email protected]>
Tested-by: Bean Huo <[email protected]>
Tested-by: Adrian Hunter <[email protected]>
Reviewed-by: Bean Huo <[email protected]>
Acked-by: Avri Altman <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>

show more ...

drivers: Add hardware timestamp engine (HTE) subsystem

Some devices can timestamp system lines/signals/Buses in real-time
using the hardware counter or other hardware means which can give
finer gran

drivers: Add hardware timestamp engine (HTE) subsystem

Some devices can timestamp system lines/signals/Buses in real-time
using the hardware counter or other hardware means which can give
finer granularity and help avoid jitter introduced by software
timestamping. To utilize such functionality, this patchset creates
HTE subsystem where devices can register themselves as providers so
that the consumers devices can request specific line from the
providers. The patch also adds compilation support in Makefile and
menu options in Kconfig.

The provider does following:
- Registers chip with the framework.
- Provides translation hook to convert logical line id.
- Provides enable/disable, request/release callbacks.
- Pushes timestamp data to HTE subsystem.

The consumer does following:
- Initializes line attribute.
- Gets HTE timestamp descriptor.
- Requests timestamp functionality.
- Puts HTE timestamp descriptor.

Signed-off-by: Dipen Patel <[email protected]>
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>

show more ...

staging: Remove the drivers for the Unisys s-Par

The Unisys sub-tree of drivers/staging contains three drivers for the
"Unisys Secure Partition" (s-Par(R)): visorhba, visorinput, visornic.

They hav

staging: Remove the drivers for the Unisys s-Par

The Unisys sub-tree of drivers/staging contains three drivers for the
"Unisys Secure Partition" (s-Par(R)): visorhba, visorinput, visornic.

They have no maintainers, in fact the only one that is listed in
MAINTAINERS has an unreacheable email address. During 2021 and 2022
several patches have been submitted to these drivers but nobody at
Unisys cared of reviewing the changes. Probably, also the
"sparmaintainer" internal list of unisys.com is not anymore read by
interested Unisys' engineers.

Therefore, remove the drivers/staging/unisys directory and delete the
relevant entries in the MAINTAINERS, Kconfig, Makefile files, then
remove also the drivers/visorbus directory which is not anymore needed
(it contained the driver for the virtualized bus for the Unisys s-Par
firmware).

Cc: David Kershner <[email protected]>
Cc: <[email protected]>
Cc: Ken Cox <[email protected]>
Suggested-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Fabio M. De Francesco <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

peci: Add core infrastructure

Intel processors provide access for various services designed to support
processor and DRAM thermal management, platform manageability and
processor interface tuning an

peci: Add core infrastructure

Intel processors provide access for various services designed to support
processor and DRAM thermal management, platform manageability and
processor interface tuning and diagnostics.
Those services are available via the Platform Environment Control
Interface (PECI) that provides a communication channel between the
processor and the Baseboard Management Controller (BMC) or other
platform management device.

This change introduces PECI subsystem by adding the initial core module
and API for controller drivers.

Co-developed-by: Jason M Bills <[email protected]>
Co-developed-by: Jae Hyun Yoo <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Acked-by: Joel Stanley <[email protected]>
Signed-off-by: Jason M Bills <[email protected]>
Signed-off-by: Jae Hyun Yoo <[email protected]>
Signed-off-by: Iwona Winiarska <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: include drivers/firmware/Kconfig unconditionally

Compile-testing drivers that require access to a firmware layer
fails when that firmware symbol is unavailable. This happened
twice this we

firmware: include drivers/firmware/Kconfig unconditionally

Compile-testing drivers that require access to a firmware layer
fails when that firmware symbol is unavailable. This happened
twice this week:

- My proposed to change to rework the QCOM_SCM firmware symbol
broke on ppc64 and others.

- The cs_dsp firmware patch added device specific firmware loader
into drivers/firmware, which broke on the same set of
architectures.

We should probably do the same thing for other subsystems as well,
but fix this one first as this is a dependency for other patches
getting merged.

Reviewed-by: Bjorn Andersson <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Acked-by: Will Deacon <[email protected]>
Acked-by: Bjorn Andersson <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Charles Keepax <[email protected]>
Cc: Simon Trimmer <[email protected]>
Cc: Michael Ellerman <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

remove the lightnvm subsystem

Lightnvm supports the OCSSD 1.x and 2.0 specs which were early attempts
to produce Open Channel SSDs and never made it into the NVMe spec
proper. They have since been

remove the lightnvm subsystem

Lightnvm supports the OCSSD 1.x and 2.0 specs which were early attempts
to produce Open Channel SSDs and never made it into the NVMe spec
proper. They have since been superceeded by NVMe enhancements such
as ZNS support. Remove the support per the deprecation schedule.

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Matias Bjørling <[email protected]>
Reviewed-by: Javier González <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>

show more ...

ide: remove the legacy ide driver

The legay ide driver has been replace with libata starting in 2003 and has
been scheduled for removal for a while. Finally kill it off so that we
can start cleanin

ide: remove the legacy ide driver

The legay ide driver has been replace with libata starting in 2003 and has
been scheduled for removal for a while. Finally kill it off so that we
can start cleaning up various bits of cruft it forced on the block layer.

Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>

show more ...

staging: comedi: move out of staging directory

The comedi code came into the kernel back in 2008, but traces its
lifetime to much much earlier. It's been polished and buffed and
there's really noth

staging: comedi: move out of staging directory

The comedi code came into the kernel back in 2008, but traces its
lifetime to much much earlier. It's been polished and buffed and
there's really nothing preventing it from being part of the "real"
portion of the kernel.

So move it to drivers/comedi/ as it belongs there.

Many thanks to the hundreds of developers who did the work to make this
happen.

Cc: Ian Abbott <[email protected]>
Cc: H Hartley Sweeten <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

cxl/mem: Introduce a driver for CXL-2.0-Type-3 endpoints

The CXL.mem protocol allows a device to act as a provider of "System
RAM" and/or "Persistent Memory" that is fully coherent as if the memory

cxl/mem: Introduce a driver for CXL-2.0-Type-3 endpoints

The CXL.mem protocol allows a device to act as a provider of "System
RAM" and/or "Persistent Memory" that is fully coherent as if the memory
was attached to the typical CPU memory controller.

With the CXL-2.0 specification a PCI endpoint can implement a "Type-3"
device interface and give the operating system control over "Host
Managed Device Memory". See section 2.3 Type 3 CXL Device.

The memory range exported by the device may optionally be described by
the platform firmware memory map, or by infrastructure like LIBNVDIMM to
provision persistent memory capacity from one, or more, CXL.mem devices.

A pre-requisite for Linux-managed memory-capacity provisioning is this
cxl_mem driver that can speak the mailbox protocol defined in section
8.2.8.4 Mailbox Registers.

For now just land the initial driver boiler-plate and Documentation/
infrastructure.

Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Acked-by: David Rientjes <[email protected]> (v1)
Cc: Jonathan Corbet <[email protected]>
Link: https://www.computeexpresslink.org/download-the-specification
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dan Williams <[email protected]>

show more ...

vdpa: move to drivers/vdpa

We have both vhost and virtio drivers that depend on vdpa.
It's easier to locate it at a top level directory otherwise
we run into issues e.g. if vhost is built-in but vir

vdpa: move to drivers/vdpa

We have both vhost and virtio drivers that depend on vdpa.
It's easier to locate it at a top level directory otherwise
we run into issues e.g. if vhost is built-in but virtio
is modular. Let's just move it up a level.

Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>

show more ...

vhost: refine vhost and vringh kconfig

Currently, CONFIG_VHOST depends on CONFIG_VIRTUALIZATION. But vhost is
not necessarily for VM since it's a generic userspace and kernel
communication protocol.

vhost: refine vhost and vringh kconfig

Currently, CONFIG_VHOST depends on CONFIG_VIRTUALIZATION. But vhost is
not necessarily for VM since it's a generic userspace and kernel
communication protocol. Such dependency may prevent archs without
virtualization support from using vhost.

To solve this, a dedicated vhost menu is created under drivers so
CONIFG_VHOST can be decoupled out of CONFIG_VIRTUALIZATION.

While at it, also squash Kconfig.vringh into vhost Kconfig file. This
avoids the trick of conditional inclusion from VOP or CAIF. Then it
will be easier to introduce new vringh users and common dependency for
both vringh and vhost.

Signed-off-by: Jason Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michael S. Tsirkin <[email protected]>

show more ...

staging: most: move core files out of the staging area

This patch moves the core module to the /drivers/most directory
and makes all necessary changes in order to not break the build.

Signed-off-by

staging: most: move core files out of the staging area

This patch moves the core module to the /drivers/most directory
and makes all necessary changes in order to not break the build.

Signed-off-by: Christian Gromm <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

gpu/trace: add a gpu total memory usage tracepoint

This change adds the below gpu memory tracepoint:
gpu_mem/gpu_mem_total: track global or proc gpu memory total usages

Per process tracking of tota

gpu/trace: add a gpu total memory usage tracepoint

This change adds the below gpu memory tracepoint:
gpu_mem/gpu_mem_total: track global or proc gpu memory total usages

Per process tracking of total gpu memory usage in the gem layer is not
appropriate and hard to implement with trivial overhead. So for the gfx
device driver layer to track total gpu memory usage both globally and
per process in an easy and uniform way is to integrate the tracepoint in
this patch to the underlying varied implementations of gpu memory
tracking system from vendors.

Putting this tracepoint in the common trace events can not only help
wean the gfx drivers off of debugfs but also greatly help the downstream
Android gpu vendors because debugfs is to be deprecated in the upcoming
Android release. Then the gpu memory tracking of both Android kernel and
the upstream linux kernel can stay closely, which can benefit the whole
kernel eco-system in the long term.

Link: http://lkml.kernel.org/r/[email protected]

Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Yiwei Zhang <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>

show more ...

staging: greybus: move the greybus core to drivers/greybus

The Greybus core code has been stable for a long time, and has been
shipping for many years in millions of phones. With the advent of a
re

staging: greybus: move the greybus core to drivers/greybus

The Greybus core code has been stable for a long time, and has been
shipping for many years in millions of phones. With the advent of a
recent Google Summer of Code project, and a number of new devices in the
works from various companies, it is time to get the core greybus code
out of staging as it really is going to be with us for a while.

Cc: Johan Hovold <[email protected]>
Cc: [email protected]
Cc: [email protected]
Acked-by: Viresh Kumar <[email protected]>
Acked-by: Alex Elder <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ide: remove the sgiioc4 driver

The SGI SN2 support is about to be removed. Remove this driver that
depends on the SN2 support.

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lkml.kern

ide: remove the sgiioc4 driver

The SGI SN2 support is about to be removed. Remove this driver that
depends on the SN2 support.

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Tony Luck <[email protected]>

show more ...

USB: Move wusbcore and UWB to staging as it is obsolete

The UWB and wusbcore code is long obsolete, so let us just move the code
out of the real part of the kernel and into the drivers/staging/
loca

USB: Move wusbcore and UWB to staging as it is obsolete

The UWB and wusbcore code is long obsolete, so let us just move the code
out of the real part of the kernel and into the drivers/staging/
location with plans to remove it entirely in a few releases.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...