#
041d2a0e |
| 16-Feb-2024 |
Duje Mihanović <duje.mihanovic@skole.hr> |
Revert "leds: Only descend into leds directory when CONFIG_NEW_LEDS is set"
This reverts commit b1ae40a5db6191c42e2e45d726407096f030ee08.
The ExpressWire library introduced in commit 25ae5f5f4168 (
Revert "leds: Only descend into leds directory when CONFIG_NEW_LEDS is set"
This reverts commit b1ae40a5db6191c42e2e45d726407096f030ee08.
The ExpressWire library introduced in commit 25ae5f5f4168 ("leds: Introduce ExpressWire library") does not depend on NEW_LEDS, but without this revert it would never get compiled if NEW_LEDS is not enabled. Revert this commit to allow the library to be compiled.
Link: https://lore.kernel.org/2cacd8dc-6150-4aa2-af9e-830a202fb0a8@app.fastmail.com Suggested-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr> Link: https://lore.kernel.org/r/20240216-expresswire-deps-v2-1-8be59c4a75f5@skole.hr Signed-off-by: Lee Jones <lee@kernel.org>
show more ...
|
#
689237ab |
| 05-Jan-2024 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/intelfb: Remove driver
From looking at the PCI IDs, every device supported by intelfb is also supported by i915. Anyone still using intelfb should please move on to i915, which does everything
fbdev/intelfb: Remove driver
From looking at the PCI IDs, every device supported by intelfb is also supported by i915. Anyone still using intelfb should please move on to i915, which does everything intelfb does but better.
Removing intelfb is motivated by the driver's excessive use of the global screen_info state. The state belongs to architecture and firmware code; device drivers should not attempt to access it. But fixing intelfb would require a significant change in the driver's probing logic. As intelfb has been obsolete for nearly 2 decades, it is probably not worth the effort. Let's just remove it. Also remove the related documentation.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Maik Broemme <mbroemme@libmpq.org> Signed-off-by: Helge Deller <deller@gmx.de>
show more ...
|
#
9a6c7821 |
| 22-Sep-2023 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
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 <wsa+renesas@sang-engineering.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
#
9431063a |
| 13-Sep-2023 |
Vadim Fedorenko <vadim.fedorenko@linux.dev> |
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 <milena.olech@intel.com> Signed-off-by: Milena Olech <milena.olech@intel.com> Co-developed-by: Michal Michalik <michal.michalik@intel.com> Signed-off-by: Michal Michalik <michal.michalik@intel.com> Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Co-developed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
e2ad626f |
| 12-Sep-2023 |
Ulf Hansson <ulf.hansson@linaro.org> |
pmdomain: Rename the genpd subsystem to pmdomain
It has been pointed out that naming a subsystem "genpd" isn't very self-explanatory and the acronym itself that means Generic PM Domain, is known onl
pmdomain: Rename the genpd subsystem to pmdomain
It has been pointed out that naming a subsystem "genpd" isn't very self-explanatory and the acronym itself that means Generic PM Domain, is known only by a limited group of people.
In a way to improve the situation, let's rename the subsystem to pmdomain, which ideally should indicate that this is about so called Power Domains or "PM domains" as we often also use within the Linux Kernel terminology.
Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230912221127.487327-1-ulf.hansson@linaro.org
show more ...
|
#
d34599bc |
| 18-Aug-2023 |
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> |
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 <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Tested-by: Conor Dooley <conor.dooley@microchip.com> # tyre-kicking on a d1 Link: https://lore.kernel.org/r/20230818135723.80612-6-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
#
305b9f4f |
| 21-Jul-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
s390: use obj-y to descend into drivers/s390/
The single build rule does not work with the drivers-y syntax. [1]
Use the standard obj-y syntax. It moves the objects from drivers/s390/ to slightly l
s390: use obj-y to descend into drivers/s390/
The single build rule does not work with the drivers-y syntax. [1]
Use the standard obj-y syntax. It moves the objects from drivers/s390/ to slightly lower address, but fixes the reported issue.
[1]: https://lore.kernel.org/linux-kbuild/d57ba55f-20a3-b836-783d-b49c8a161b6e@kernel.org/T/#m27f781ab60acadfed8a9e9642f30d5414a5e2df3
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230721171358.3612099-1-masahiroy@kernel.org Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
#
c1e213e5 |
| 30-Jun-2023 |
Ulf Hansson <ulf.hansson@linaro.org> |
genpd: Create a new subsystem directory to host genpd providers
There are currently ~60 users of the genpd provider interface, which implementations are sprinkled across various subsystems. To simpl
genpd: Create a new subsystem directory to host genpd providers
There are currently ~60 users of the genpd provider interface, which implementations are sprinkled across various subsystems. To simplify with maintenance let's create a new subsystem (drivers/genpd) and start moving the providers in there.
My intention is also to host a git tree to collect and to get the patches tested/integrated through the linux-next tree. Ideally this should release some of the burden on the soc maintainers.
Note that, I will of course require acks/reviews from the current platform maintainers, hence the MAINTAINERS file needs to be updated accordingly for each genpd provider that is moved into the new genpd subsystem.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
2959ab24 |
| 13-Mar-2023 |
Nipun Gupta <nipun.gupta@amd.com> |
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 <nipun.gupta@amd.com> Reviewed-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Tested-by: Nikhil Agarwal <nikhil.agarwal@amd.com> Link: https://lore.kernel.org/r/20230313132636.31850-2-nipun.gupta@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
8a3d95ea |
| 14-Feb-2023 |
Arnd Bergmann <arnd@arndb.de> |
dax/hmem: build hmem device support as module if possible
When device_hmem.o is enabled but dax itself is a loadable module, the dax_hmem support fails to link because Kbuild never compiles built-in
dax/hmem: build hmem device support as module if possible
When device_hmem.o is enabled but dax itself is a loadable module, the dax_hmem support fails to link because Kbuild never compiles built-in code under drivers/dax:
ERROR: modpost: "walk_hmem_resources" [drivers/dax/hmem/dax_hmem.ko] undefined!
Make sure that drivers/dax is entered for compiling built-in code even with CONFIG_DAX=m.
Fixes: 7dab174e2e27 ("dax/hmem: Move hmem device registration to dax_hmem.ko") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230214131913.1431969-1-arnd@kernel.org Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
#
67d7c302 |
| 28-Jan-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: remove --include-dir MAKEFLAG from top Makefile
I added $(srctree)/ to some included Makefiles in the following commits:
- 3204a7fb98a3 ("kbuild: prefix $(srctree)/ to some included Makefi
kbuild: remove --include-dir MAKEFLAG from top Makefile
I added $(srctree)/ to some included Makefiles in the following commits:
- 3204a7fb98a3 ("kbuild: prefix $(srctree)/ to some included Makefiles") - d82856395505 ("kbuild: do not require sub-make for separate output tree builds")
They were a preparation for removing --include-dir flag.
I have never thought --include-dir useful. Rather, it _is_ harmful.
For example, run the following commands:
$ make -s ARCH=x86 mrproper defconfig $ make ARCH=arm O=foo dtbs make[1]: Entering directory '/tmp/linux/foo' HOSTCC scripts/basic/fixdep Error: kernelrelease not valid - run 'make prepare' to update it UPD include/config/kernel.release make[1]: Leaving directory '/tmp/linux/foo'
The first command configures the source tree for x86. The next command tries to build ARM device trees in the separate foo/ directory - this must stop because the directory foo/ has not been configured yet.
However, due to --include-dir=$(abs_srctree), the top Makefile includes the wrong include/config/auto.conf from the source tree and continues building. Kbuild traverses the directory tree, but of course it does not work correctly. The Error message is also pointless - 'make prepare' does not help at all for fixing the issue.
This commit fixes more arch Makefile, and finally removes --include-dir from the top Makefile.
There are more breakages under drivers/, but I do not volunteer to fix them all. I just moved --include-dir to drivers/Makefile.
With this commit, the second command will stop with a sensible message.
$ make -s ARCH=x86 mrproper defconfig $ make ARCH=arm O=foo dtbs make[1]: Entering directory '/tmp/linux/foo' SYNC include/config/auto.conf.cmd *** *** The source tree is not clean, please run 'make ARCH=arm mrproper' *** in /tmp/linux *** make[2]: *** [../Makefile:646: outputmakefile] Error 1 /tmp/linux/Makefile:770: include/config/auto.conf.cmd: No such file or directory make[1]: *** [/tmp/linux/Makefile:793: include/config/auto.conf.cmd] Error 2 make[1]: Leaving directory '/tmp/linux/foo' make: *** [Makefile:226: __sub-make] Error 2
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
72f2b0b2 |
| 30-Jan-2023 |
Ondrej Zary <linux@zary.sk> |
drivers/block: Move PARIDE protocol modules to drivers/ata/pata_parport
Move PARIDE protocol modules out of drivers/block into drivers/ata/pata_parport and update the CONFIG_ symbol names to PATA_PA
drivers/block: Move PARIDE protocol modules to drivers/ata/pata_parport
Move PARIDE protocol modules out of drivers/block into drivers/ata/pata_parport and update the CONFIG_ symbol names to PATA_PARPORT.
[Damien] The pata_parport driver file itsef is also moved together with the protocol modules in drivers/ata/pata_parport.
Signed-off-by: Ondrej Zary <linux@zary.sk> Acked-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
show more ...
|
#
246a1c4c |
| 23-Jan-2023 |
Ondrej Zary <linux@zary.sk> |
ata: pata_parport: add driver (PARIDE replacement)
The pata_parport is a libata-based replacement of the old PARIDE subsystem - driver for parallel port IDE devices. It uses the original paride low-
ata: pata_parport: add driver (PARIDE replacement)
The pata_parport is a libata-based replacement of the old PARIDE subsystem - driver for parallel port IDE devices. It uses the original paride low-level protocol drivers but does not need the high-level drivers (pd, pcd, pf, pt, pg). The IDE devices behind parallel port adapters are handled by the ATA layer.
This will allow paride and its high-level drivers to be removed.
Unfortunately, libata drivers cannot sleep so pata_parport claims parport before activating the ata host and keeps it claimed (and protocol connected) until the ata host is removed. This means that no devices can be chained (neither other pata_parport devices nor a printer).
paride and pata_parport are mutually exclusive because the compiled protocol drivers are incompatible.
Tested with: - Imation SuperDisk LS-120 and HP C4381A (EPAT) - Freecom Parallel CD (FRPW) - Toshiba Mobile CD-RW 2793008 w/Freecom Parallel Cable rev.903 (FRIQ) - Backpack CD-RW 222011 and CD-RW 19350 (BPCK6)
The following bugs in low-level protocol drivers were found and will be fixed later:
Note: EPP-32 mode is buggy in EPAT - and also in all other protocol drivers - they don't handle non-multiple-of-4 block transfers correctly. This causes problems with LS-120 drive. There is also another bug in EPAT: EPP modes don't work unless a 4-bit or 8-bit mode is used first (probably some initialization missing?). Once the device is initialized, EPP works until power cycle.
So after device power on, you have to: echo "parport0 epat 0" >/sys/bus/pata_parport/new_device echo pata_parport.0 >/sys/bus/pata_parport/delete_device echo "parport0 epat 4" >/sys/bus/pata_parport/new_device (autoprobe will initialize correctly as it tries the slowest modes first but you'll get the broken EPP-32 mode)
Note: EPP modes are buggy in FRPW, only modes 0 and 1 work.
Signed-off-by: Ondrej Zary <linux@zary.sk> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Acked-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
show more ...
|
#
e65e175b |
| 26-Dec-2022 |
Oded Gabbay <ogabbay@kernel.org> |
habanalabs: move driver to accel subsystem
Now that we have a subsystem for compute accelerators, move the habanalabs driver to it.
This patch only moves the files and fixes the Makefiles. Future p
habanalabs: move driver to accel subsystem
Now that we have a subsystem for compute accelerators, move the habanalabs driver to it.
This patch only moves the files and fixes the Makefiles. Future patches will change the existing code to register to the accel subsystem and expose the accel device char files instead of the habanalabs device char files.
Update the MAINTAINERS file to reflect this change.
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
35b13763 |
| 17-Jan-2023 |
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> |
accel/ivpu: Introduce a new DRM driver for Intel VPU
VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications.
The
accel/ivpu: Introduce a new DRM driver for Intel VPU
VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications.
The VPU device consist of following components: - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components
This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation).
Module sources are at drivers/accel/ivpu and module name is "intel_vpu.ko".
This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware
Co-developed-by: Krystian Pradzynski <krystian.pradzynski@linux.intel.com> Signed-off-by: Krystian Pradzynski <krystian.pradzynski@linux.intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230117092723.60441-2-jacek.lawrynowicz@linux.intel.com
show more ...
|
#
25621bcc |
| 03-Nov-2022 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: Kconfig: split HID support and hid-core compilation
Currently, we step into drivers/hid/ based on the value of CONFIG_HID.
However, that value is a tristate, meaning that it can be a module.
HID: Kconfig: split HID support and hid-core compilation
Currently, we step into drivers/hid/ based on the value of CONFIG_HID.
However, that value is a tristate, meaning that it can be a module.
As per the documentation, if we jump into the subdirectory by following an obj-m, we can not compile anything inside that subdirectory in vmlinux. It is considered as a bug.
To make things more friendly to HID-BPF, split HID (the HID core parameter) from HID_SUPPORT (do we want any kind of HID support in the system?), and make this new config a boolean.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|
#
ff0de066 |
| 16-Aug-2022 |
Yicong Yang <yangyicong@hisilicon.com> |
hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device
HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated Endpoint(RCiEP) device, providing
hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device
HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated Endpoint(RCiEP) device, providing the capability to dynamically monitor and tune the PCIe traffic and trace the TLP headers.
Add the driver for the device to enable the trace function. Register PMU device of PTT trace, then users can use trace through perf command. The driver makes use of perf AUX trace function and support the following events to configure the trace:
- filter: select Root port or Endpoint to trace - type: select the type of traced TLP headers - direction: select the direction of traced TLP headers - format: select the data format of the traced TLP headers
This patch initially add basic trace support of PTT device.
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20220816114414.4092-3-yangyicong@huawei.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
show more ...
|
#
1045a067 |
| 29-Jun-2022 |
Christoph Hellwig <hch@lst.de> |
remove CONFIG_ANDROID
The ANDROID config symbol is only used to guard the binder config symbol and to inject completely random config changes. Remove it as it is obviously a bad idea.
Acked-by: Pa
remove CONFIG_ANDROID
The ANDROID config symbol is only used to guard the binder config symbol and to inject completely random config changes. Remove it as it is obviously a bad idea.
Acked-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220629150102.1582425-2-hch@lst.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
35ba63b8 |
| 06-Jun-2022 |
Arnd Bergmann <arnd@arndb.de> |
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 <arnd@arndb.de> Link: https://lore.kernel.org/r/20220606084109.4108188-3-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
dd11376b |
| 11-May-2022 |
Bart Van Assche <bvanassche@acm.org> |
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/20220511212552.655341-1-bvanassche@acm.org Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Avri Altman <avri.altman@wdc.com> Cc: Bean Huo <beanhuo@micron.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Keoseong Park <keosung.park@samsung.com> Tested-by: Bean Huo <beanhuo@micron.com> Tested-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Bean Huo <beanhuo@micron.com> Acked-by: Avri Altman <avri.altman@wdc.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
#
31ab09b4 |
| 22-Apr-2022 |
Dipen Patel <dipenp@nvidia.com> |
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 <dipenp@nvidia.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
#
9ea4dcf4 |
| 22-Apr-2022 |
Dan Williams <dan.j.williams@intel.com> |
PM: CXL: Disable suspend
The CXL specification claims S3 support at a hardware level, but at a system software level there are some missing pieces. Section 9.4 (CXL 2.0) rightly claims that "CXL mem
PM: CXL: Disable suspend
The CXL specification claims S3 support at a hardware level, but at a system software level there are some missing pieces. Section 9.4 (CXL 2.0) rightly claims that "CXL mem adapters may need aux power to retain memory context across S3", but there is no enumeration mechanism for the OS to determine if a given adapter has that support. Moreover the save state and resume image for the system may inadvertantly end up in a CXL device that needs to be restored before the save state is recoverable. I.e. a circular dependency that is not resolvable without a third party save-area.
Arrange for the cxl_mem driver to fail S3 attempts. This still nominaly allows for suspend, but requires unbinding all CXL memory devices before the suspend to ensure the typical DRAM flow is taken. The cxl_mem unbind flow is intended to also tear down all CXL memory regions associated with a given cxl_memdev.
It is reasonable to assume that any device participating in a System RAM range published in the EFI memory map is covered by aux power and save-area outside the device itself. So this restriction can be minimized in the future once pre-existing region enumeration support arrives, and perhaps a spec update to clarify if the EFI memory map is sufficent for determining the range of devices managed by platform-firmware for S3 support.
Per Rafael, if the CXL configuration prevents suspend then it should fail early before tasks are frozen, and mem_sleep should stop showing 'mem' as an option [1]. Effectively CXL augments the platform suspend ->valid() op since, for example, the ACPI ops are not aware of the CXL / PCI dependencies. Given the split role of platform firmware vs OS provisioned CXL memory it is up to the cxl_mem driver to determine if the CXL configuration has elements that platform firmware may not be prepared to restore.
Link: https://lore.kernel.org/r/CAJZ5v0hGVN_=3iU8OLpHY3Ak35T5+JcBM-qs8SbojKrpd0VXsA@mail.gmail.com [1] Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Len Brown <len.brown@intel.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/165066828317.3907920.5690432272182042556.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
#
e5f45b01 |
| 14-Apr-2022 |
Fabio M. De Francesco <fmdefrancesco@gmail.com> |
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 <david.kershner@unisys.com> Cc: <sparmaintainer@unisys.com> Cc: Ken Cox <jkc@redhat.com> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20220414103217.32058-1-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
6523d3b2 |
| 08-Feb-2022 |
Iwona Winiarska <iwona.winiarska@intel.com> |
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 <jason.m.bills@linux.intel.com> Co-developed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Jason M Bills <jason.m.bills@linux.intel.com> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20220208153639.255278-5-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
27d9839f |
| 06-Dec-2021 |
Arnd Bergmann <arnd@arndb.de> |
virtio: always enter drivers/virtio/
When neither VIRTIO_PCI_LIB nor VIRTIO are enabled, but the alibaba vdpa driver is, the kernel runs into a link error because the legacy virtio module never gets
virtio: always enter drivers/virtio/
When neither VIRTIO_PCI_LIB nor VIRTIO are enabled, but the alibaba vdpa driver is, the kernel runs into a link error because the legacy virtio module never gets built:
x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_set_features': eni_vdpa.c:(.text+0x23f): undefined reference to `vp_legacy_set_features' x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_set_vq_state': eni_vdpa.c:(.text+0x2fe): undefined reference to `vp_legacy_get_queue_enable' x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_set_vq_address': eni_vdpa.c:(.text+0x376): undefined reference to `vp_legacy_set_queue_address' x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_set_vq_ready': eni_vdpa.c:(.text+0x3b4): undefined reference to `vp_legacy_set_queue_address' x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_free_irq': eni_vdpa.c:(.text+0x460): undefined reference to `vp_legacy_queue_vector' x86_64-linux-ld: eni_vdpa.c:(.text+0x4b7): undefined reference to `vp_legacy_config_vector' x86_64-linux-ld: drivers/vdpa/alibaba/eni_vdpa.o: in function `eni_vdpa_reset':
When VIRTIO_PCI_LIB was added, it was correctly added to drivers/Makefile as well, but for the legacy module, this is missing. Solve this by always entering drivers/virtio during the build and letting its Makefile take care of the individual options, rather than having a separate line for each sub-option.
Fixes: 64b9f64f80a6 ("vdpa: introduce virtio pci driver") Fixes: e85087beedca ("eni_vdpa: add vDPA driver for Alibaba ENI") Fixes: d89c8169bd70 ("virtio-pci: introduce legacy device module") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20211206085034.2836099-1-arnd@kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|