Just a bunch of fixes and cleanups, mostly very simple. Several
features are merged through net-next this time around.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQFDBAABCgAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmkvRoEPHG1zdEByZWRo
YXQuY29tAAoJECgfDbjSjVRpKK4H/2VhNPqr3OL3RZJsHv6iJ6PQJU0JYRfqEH6B
x1nOPEsTt34ypLfSqP15DWyOeshTENknnnYuZ8Gzyiim9R/l+2OyMLW0bsCqdfV8
L/FyDJPMW3WmfesMlUUMKRwFEzFolj+SrlH+Us9UUd1wKbC1ctHJ+4Ov5hw5z5/e
wEVeIwf/WcAU0CyqolTF72+0BSIU7ml0wrzxBp05hkeDnugVmhAskQpb5p0SNI/d
u4Zfvuz9s1Qq9TGpwWaibWTBQ3F6Hbyw3Pr+ojwVSoCufnVDQ/FuCZfe607lv7Dh
YZuHc4PtFRfLgmwNuHSnPv7S7fp00kHAeEGbPpKyh09UjDtqC+A=
=lXGm
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio updates from Michael Tsirkin:
"Just a bunch of fixes and cleanups, mostly very simple. Several
features were merged through net-next this time around"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
virtio_pci: drop kernel.h
vhost: switch to arrays of feature bits
vhost/test: add test specific macro for features
virtio: clean up features qword/dword terms
vduse: add WQ_PERCPU to alloc_workqueue users
virtio_balloon: add WQ_PERCPU to alloc_workqueue users
vdpa/pds: use %pe for ERR_PTR() in event handler registration
vhost: Fix kthread worker cgroup failure handling
virtio: vdpa: Fix reference count leak in octep_sriov_enable()
vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues
virtio: fix map ops comment
virtio: fix virtqueue_set_affinity() docs
virtio: standardize Returns documentation style
virtio: fix grammar in virtio_map_ops docs
virtio: fix grammar in virtio_queue_info docs
virtio: fix whitespace in virtio_config_ops
virtio: fix typo in virtio_device_ready() comment
virtio: fix kernel-doc for mapping/free_coherent functions
virtio_vdpa: fix misleading return in void function
- Minor driver bug fixes and updates to cxgb4, rxe, rdmavt, bnxt_re, mlx5
- Many bug fix patches for irdma
- WQ_PERCPU annotations and system_dfl_wq changes
- Improved mlx5 support for "other eswitches" and multiple PFs
- 1600Gbps link speed reporting support. Four Digits Now!
- New driver bng_en for latest generation Broadcom NICs
- Bonding support for hns
- Adjust mlx5's hmm based ODP to work with the very large address space
created by the new 5 level paging default on x86
- Lockdep fixups in rxe and siw
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCaS9AIgAKCRCFwuHvBreF
YXS2AP99rRv3hue5jLELuDqyPOORTzVfpKfAOcR2V3l30AP3mwEA1j/jontz1Ak+
oTNrL7Tv1rAxopB24yTLuFmIXEXHCAE=
=3PJv
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma updates from Jason Gunthorpe:
"This has another new RDMA driver 'bng_en' for latest generation
Broadcom NICs. There might be one more new driver still to come.
Otherwise it is a fairly quite cycle. Summary:
- Minor driver bug fixes and updates to cxgb4, rxe, rdmavt, bnxt_re,
mlx5
- Many bug fix patches for irdma
- WQ_PERCPU annotations and system_dfl_wq changes
- Improved mlx5 support for "other eswitches" and multiple PFs
- 1600Gbps link speed reporting support. Four Digits Now!
- New driver bng_en for latest generation Broadcom NICs
- Bonding support for hns
- Adjust mlx5's hmm based ODP to work with the very large address
space created by the new 5 level paging default on x86
- Lockdep fixups in rxe and siw"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (65 commits)
RDMA/rxe: reclassify sockets in order to avoid false positives from lockdep
RDMA/siw: reclassify sockets in order to avoid false positives from lockdep
RDMA/bng_re: Remove prefetch instruction
RDMA/core: Reduce cond_resched() frequency in __ib_umem_release
RDMA/irdma: Fix SRQ shadow area address initialization
RDMA/irdma: Remove doorbell elision logic
RDMA/irdma: Do not set IBK_LOCAL_DMA_LKEY for GEN3+
RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY
RDMA/irdma: Add missing mutex destroy
RDMA/irdma: Fix SIGBUS in AEQ destroy
RDMA/irdma: Add a missing kfree of struct irdma_pci_f for GEN2
RDMA/irdma: Fix data race in irdma_free_pble
RDMA/irdma: Fix data race in irdma_sc_ccq_arm
RDMA/mlx5: Add support for 1600_8x lane speed
RDMA/core: Add new IB rate for XDR (8x) support
IB/mlx5: Reduce IMR KSM size when 5-level paging is enabled
RDMA/bnxt_re: Pass correct flag for dma mr creation
RDMA/bnxt_re: Fix the inline size for GenP7 devices
RDMA/hns: Support reset recovery for bond
RDMA/hns: Support link state reporting for bond
...
- Expand IOMMU_IOAS_MAP_FILE to accept a DMABUF exported from VFIO. This
is the first step to broader DMABUF support in iommufd, right now it
only works with VFIO. This closes the last functional gap with classic
VFIO type 1 to safely support PCI peer to peer DMA by mapping the VFIO
device's MMIO into the IOMMU.
- Relax SMMUv3 restrictions on nesting domains to better support qemu's
sequence to have an identity mapping before the vSID is established.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCaS8DrgAKCRCFwuHvBreF
YY/kAP0Q1s7LkVb83uQb8kIW3xKzEnFNTlhrSSGV5UBuYLbaDgD+J+y+4VrSkJem
85LMipmzaoZdHqtxMhQWrlYbZMr9TAM=
=BacK
-----END PGP SIGNATURE-----
Merge tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd
Pull iommufd updates from Jason Gunthorpe:
"This is a pretty consequential cycle for iommufd, though this pull is
not too big. It is based on a shared branch with VFIO that introduces
VFIO_DEVICE_FEATURE_DMA_BUF a DMABUF exporter for VFIO device's MMIO
PCI BARs. This was a large multiple series journey over the last year
and a half.
Based on that work IOMMUFD gains support for VFIO DMABUF's in its
existing IOMMU_IOAS_MAP_FILE, which closes the last major gap to
support PCI peer to peer transfers within VMs.
In Joerg's iommu tree we have the "generic page table" work which aims
to consolidate all the duplicated page table code in every iommu
driver into a single algorithm. This will be used by iommufd to
implement unique page table operations to start adding new features
and improve performance.
In here:
- Expand IOMMU_IOAS_MAP_FILE to accept a DMABUF exported from VFIO.
This is the first step to broader DMABUF support in iommufd, right
now it only works with VFIO. This closes the last functional gap
with classic VFIO type 1 to safely support PCI peer to peer DMA by
mapping the VFIO device's MMIO into the IOMMU.
- Relax SMMUv3 restrictions on nesting domains to better support
qemu's sequence to have an identity mapping before the vSID is
established"
* tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd:
iommu/arm-smmu-v3-iommufd: Allow attaching nested domain for GBPA cases
iommufd/selftest: Add some tests for the dmabuf flow
iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE
iommufd: Have iopt_map_file_pages convert the fd to a file
iommufd: Have pfn_reader process DMABUF iopt_pages
iommufd: Allow MMIO pages in a batch
iommufd: Allow a DMABUF to be revoked
iommufd: Do not map/unmap revoked DMABUFs
iommufd: Add DMABUF to iopt_pages
vfio/pci: Add vfio_pci_dma_buf_iommufd_map()
- Move libvfio selftest artifacts in preparation of more tightly
coupled integration with KVM selftests. (David Matlack)
- Fix comment typo in mtty driver. (Chu Guangqing)
- Support for new hardware revision in the hisi_acc vfio-pci variant
driver where the migration registers can now be accessed via the PF.
When enabled for this support, the full BAR can be exposed to the
user. (Longfang Liu)
- Fix vfio cdev support for VF token passing, using the correct size
for the kernel structure, thereby actually allowing userspace to
provide a non-zero UUID token. Also set the match token callback for
the hisi_acc, fixing VF token support for this this vfio-pci variant
driver. (Raghavendra Rao Ananta)
- Introduce internal callbacks on vfio devices to simplify and
consolidate duplicate code for generating VFIO_DEVICE_GET_REGION_INFO
data, removing various ioctl intercepts with a more structured
solution. (Jason Gunthorpe)
- Introduce dma-buf support for vfio-pci devices, allowing MMIO regions
to be exposed through dma-buf objects with lifecycle managed through
move operations. This enables low-level interactions such as a
vfio-pci based SPDK drivers interacting directly with dma-buf capable
RDMA devices to enable peer-to-peer operations. IOMMUFD is also now
able to build upon this support to fill a long standing feature gap
versus the legacy vfio type1 IOMMU backend with an implementation of
P2P support for VM use cases that better manages the lifecycle of the
P2P mapping. (Leon Romanovsky, Jason Gunthorpe, Vivek Kasireddy)
- Convert eventfd triggering for error and request signals to use RCU
mechanisms in order to avoid a 3-way lockdep reported deadlock issue.
(Alex Williamson)
- Fix a 32-bit overflow introduced via dma-buf support manifesting with
large DMA buffers. (Alex Mastro)
- Convert nvgrace-gpu vfio-pci variant driver to insert mappings on
fault rather than at mmap time. This conversion serves both to make
use of huge PFNMAPs but also to both avoid corrected RAS events
during reset by now being subject to vfio-pci-core's use of
unmap_mapping_range(), and to enable a device readiness test after
reset. (Ankit Agrawal)
- Refactoring of vfio selftests to support multi-device tests and split
code to provide better separation between IOMMU and device objects.
This work also enables a new test suite addition to measure parallel
device initialization latency. (David Matlack)
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEQvbATlQL0amee4qQI5ubbjuwiyIFAmkvV3IRHGFsZXhAc2hh
emJvdC5vcmcACgkQI5ubbjuwiyIpIQ/9GwpjLH5Vdv0v2d9mkHmZIWFpG/tr3zJa
+spQqOjO0etASc67PtIJArT9pWib+s6O8OaG7iFrdNR65HCSsXSZbIGbMThPODfy
DdDj1ipAqMVwcaCZT8un2N8Sktu9YpFQMvc5IoXWWYhw88vili7bBx+OTrEFV2T0
6qQijSBdhw1TXVFHG6BGSmqmisyMepIebA6GmPWdfYu6BfoWBYMdcMjDwd1J61Q5
DDwFRzn/Dz2Tvb1jbXiiRMRuFIuegFQii+wtd30S/cRPFZhZLWzc+drimC6oOFiQ
qL19vQQsBPnLtGvch40HsET/AbY5w0pLCkYX5qacxP3sq27+N+KuotzCvbnVMN+H
e2BqOCujyoce8z1Br6BzV71Lr2yzPDcc5pXTuEuuBT+J/ptOY8hfEikOj85s5Wzj
aKsTrdDRGMrn/o11NkGSzYwFcMs9MxCX9mo98U6OkWDr0+cmPLf4LGZgpJudWg4E
POUlzPpnzJrTlX5d+OqCdKJG0a1hTlTa2udzRa5hCDANHaZWLoAssfgSEKfV9xt1
PzOMf0UIJmPJmFcw/OpMO72/5xp8O4WslJS0ulSm6vrAJDtutLApHZ7bJ44KniNd
4vte+gOjyZY8ibTDKRULhXVlCDxkEnZjRBbApgI9HJD61IElOzjqohRuRx77J09B
7c8OSLI8d1U=
=tpee
-----END PGP SIGNATURE-----
Merge tag 'vfio-v6.19-rc1' of https://github.com/awilliam/linux-vfio
Pull VFIO updates from Alex Williamson:
- Move libvfio selftest artifacts in preparation of more tightly
coupled integration with KVM selftests (David Matlack)
- Fix comment typo in mtty driver (Chu Guangqing)
- Support for new hardware revision in the hisi_acc vfio-pci variant
driver where the migration registers can now be accessed via the PF.
When enabled for this support, the full BAR can be exposed to the
user (Longfang Liu)
- Fix vfio cdev support for VF token passing, using the correct size
for the kernel structure, thereby actually allowing userspace to
provide a non-zero UUID token. Also set the match token callback for
the hisi_acc, fixing VF token support for this this vfio-pci variant
driver (Raghavendra Rao Ananta)
- Introduce internal callbacks on vfio devices to simplify and
consolidate duplicate code for generating VFIO_DEVICE_GET_REGION_INFO
data, removing various ioctl intercepts with a more structured
solution (Jason Gunthorpe)
- Introduce dma-buf support for vfio-pci devices, allowing MMIO regions
to be exposed through dma-buf objects with lifecycle managed through
move operations. This enables low-level interactions such as a
vfio-pci based SPDK drivers interacting directly with dma-buf capable
RDMA devices to enable peer-to-peer operations. IOMMUFD is also now
able to build upon this support to fill a long standing feature gap
versus the legacy vfio type1 IOMMU backend with an implementation of
P2P support for VM use cases that better manages the lifecycle of the
P2P mapping (Leon Romanovsky, Jason Gunthorpe, Vivek Kasireddy)
- Convert eventfd triggering for error and request signals to use RCU
mechanisms in order to avoid a 3-way lockdep reported deadlock issue
(Alex Williamson)
- Fix a 32-bit overflow introduced via dma-buf support manifesting with
large DMA buffers (Alex Mastro)
- Convert nvgrace-gpu vfio-pci variant driver to insert mappings on
fault rather than at mmap time. This conversion serves both to make
use of huge PFNMAPs but also to both avoid corrected RAS events
during reset by now being subject to vfio-pci-core's use of
unmap_mapping_range(), and to enable a device readiness test after
reset (Ankit Agrawal)
- Refactoring of vfio selftests to support multi-device tests and split
code to provide better separation between IOMMU and device objects.
This work also enables a new test suite addition to measure parallel
device initialization latency (David Matlack)
* tag 'vfio-v6.19-rc1' of https://github.com/awilliam/linux-vfio: (65 commits)
vfio: selftests: Add vfio_pci_device_init_perf_test
vfio: selftests: Eliminate INVALID_IOVA
vfio: selftests: Split libvfio.h into separate header files
vfio: selftests: Move vfio_selftests_*() helpers into libvfio.c
vfio: selftests: Rename vfio_util.h to libvfio.h
vfio: selftests: Stop passing device for IOMMU operations
vfio: selftests: Move IOVA allocator into iova_allocator.c
vfio: selftests: Move IOMMU library code into iommu.c
vfio: selftests: Rename struct vfio_dma_region to dma_region
vfio: selftests: Upgrade driver logging to dev_err()
vfio: selftests: Prefix logs with device BDF where relevant
vfio: selftests: Eliminate overly chatty logging
vfio: selftests: Support multiple devices in the same container/iommufd
vfio: selftests: Introduce struct iommu
vfio: selftests: Rename struct vfio_iommu_mode to iommu_mode
vfio: selftests: Allow passing multiple BDFs on the command line
vfio: selftests: Split run.sh into separate scripts
vfio: selftests: Move run.sh into scripts directory
vfio/nvgrace-gpu: wait for the GPU mem to be ready
vfio/nvgrace-gpu: Inform devmem unmapped after reset
...
Including:
- Introduction of the generic IO page-table framework with support for
Intel and AMD IOMMU formats from Jason. This has good potential for
unifying more IO page-table implementations and making future
enhancements more easy. But this also needed quite some fixes during
development. All known issues have been fixed, but my feeling is that
there is a higher potential than usual that more might be needed.
- Intel VT-d updates:
- Use right invalidation hint in qi_desc_iotlb().
- Reduce the scope of INTEL_IOMMU_FLOPPY_WA.
- ARM-SMMU updates:
- Qualcomm device-tree binding updates for Kaanapali and Glymur SoCs
and a new clock for the TBU.
- Fix error handling if level 1 CD table allocation fails.
- Permit more than the architectural maximum number of SMRs for funky
Qualcomm mis-implementations of SMMUv2.
- Mediatek driver:
- MT8189 iommu support.
- Move ARM IO-pgtable selftests to kunit.
- Device leak fixes for a couple of drivers.
- Random smaller fixes and improvements.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEr9jSbILcajRFYWYyK/BELZcBGuMFAmktjWgACgkQK/BELZcB
GuMQgA//YljqMVbMmYpFQF/9nXsyTvkpzaaVqj3CscjfnLJQ7YNIrWHLMw4xcZP7
c2zsSDMPc5LAe2nkyNPvMeFufsbDOYE1CcbqFfZhNqwKGWIVs7J1j73aqJXKfXB4
RaVv5GA1NFeeIRRKPx/ZpD9W1WiR9PiUQXBxNTAJLzbBNhcTJzo+3YuSpJ6ckOak
aG67Aox6Dwq/u0gHy8gWnuA2XL6Eit+nQbod7TfchHoRu+TUdbv8qWL+sUChj+u/
IlyBt1YL/do3bJC0G1G2E81J1KGPU/OZRfB34STQKlopEdXX17ax3b2X0bt3Hz/h
9Yk3BLDtGMBQ0aVZzAZcOLLlBlEpPiMKBVuJQj29kK9KJSYfmr2iolOK0cGyt+kv
DfQ8+nv6HRFMbwjetfmhGYf6WemPcggvX44Hm/rgR2qbN3P+Q8/klyyH8MLuQeqO
ttoQIwDd9DYKJelmWzbLgpb2vGE3O0EAFhiTcCKOk643PaudfengWYKZpJVIIqtF
nEUEpk17HlpgFkYrtmIE7CMONqUGaQYO84R3j7DXcYXYAvqQJkhR3uJejlWQeh8x
uMc9y04jpg3p5vC5c7LfkQ3at3p/jf7jzz4GuNoZP5bdVIUkwXXolir0ct3/oby3
/bXXNA1pSaRuUADm7pYBBhKYAFKC7vCSa8LVaDR3CB95aNZnvS0=
=KG7j
-----END PGP SIGNATURE-----
Merge tag 'iommu-updates-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux
Pull iommu updates from Joerg Roedel:
- Introduction of the generic IO page-table framework with support for
Intel and AMD IOMMU formats from Jason.
This has good potential for unifying more IO page-table
implementations and making future enhancements more easy. But this
also needed quite some fixes during development. All known issues
have been fixed, but my feeling is that there is a higher potential
than usual that more might be needed.
- Intel VT-d updates:
- Use right invalidation hint in qi_desc_iotlb()
- Reduce the scope of INTEL_IOMMU_FLOPPY_WA
- ARM-SMMU updates:
- Qualcomm device-tree binding updates for Kaanapali and Glymur SoCs
and a new clock for the TBU.
- Fix error handling if level 1 CD table allocation fails.
- Permit more than the architectural maximum number of SMRs for
funky Qualcomm mis-implementations of SMMUv2.
- Mediatek driver:
- MT8189 iommu support
- Move ARM IO-pgtable selftests to kunit
- Device leak fixes for a couple of drivers
- Random smaller fixes and improvements
* tag 'iommu-updates-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: (81 commits)
iommupt/vtd: Support mgaw's less than a 4 level walk for first stage
iommupt/vtd: Allow VT-d to have a larger table top than the vasz requires
powerpc/pseries/svm: Make mem_encrypt.h self contained
genpt: Make GENERIC_PT invisible
iommupt: Avoid a compiler bug with sw_bit
iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-metal
iommupt: Fix unlikely flows in increase_top()
iommu/amd: Propagate the error code returned by __modify_irte_ga() in modify_irte_ga()
MAINTAINERS: Update my email address
iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables
dt-bindings: iommu: qcom_iommu: Allow 'tbu' clock
iommu/vt-d: Restore previous domain::aperture_end calculation
iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb
iommu/vt-d: Set INTEL_IOMMU_FLOPPY_WA depend on BLK_DEV_FD
iommu/tegra: fix device leak on probe_device()
iommu/sun50i: fix device leak on of_xlate()
iommu/omap: simplify probe_device() error handling
iommu/omap: fix device leaks on probe_device()
iommu/mediatek-v1: add missing larb count sanity check
iommu/mediatek-v1: fix device leaks on probe()
...
Misc:
- Remove incorrect page-allocator quirk section in documentation.
- Remove unused devm_cxl_port_enumerate_dports() function.
- Fix typo in cdat.c code comment.
- Replace use of system_wq with system_percpu_wq
- Add locked CXL decoder support for region removal.
- Return when generic target updated
- Rename region_res_match_cxl_range() to spa_maps_hpa()
- Clarify comment in spa_maps_hpa()
Enable unit testing for XOR address translation of SPA to DPA and vice versa.
- Refactor address translation funcs for testing in cxl_region.
- Make the XOR calculations available for testing.
- Add cxl_translate module for address translation testing in cxl_test.
Extended Linear Cache changes:
- Add extended linear cache size sysfs attribute.
- Adjust failure emission of extended linear cache detection in cxl_acpi.
- Added extended linear cache unit testing support in cxl_test
Preparation refactor patches for PRM translation support.
- Simplify cxl_rd_ops allocation and handling.
- Group xor arithmetric setup code in a single block.
- Remove local variable @inc in cxl_port_setup_targets()
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE5DAy15EJMCV1R6v9YGjFFmlTOEoFAmktwo8ACgkQYGjFFmlT
OEo+zw/+JvSlKu6H9XPB6eiMS4i7aWpo1/k8uqpejZp29jxmZFe4N+YYuvVaMlEB
c7FhMd0e+jXC+/GocsleGyvXSXUJf+mgkrcsRHFNkwaZHSFud2LIbbyrwXRh3wdN
KPViMdhrB12YuCASkZLMXf8PIQT5apDUhXoo9F/pxtlFjlpWnOjqewL7dmNNLK9i
IIfdfrGUb90CyFDCLMreJOPnsRm4TFKaG4ITAImZOlj94Gx9KSdsS0Dcfzm0tZr/
sYjSamgN3ctoOVbzEhEy3Kmy3NOSLyWD8MOUzSXggZo2dU9u1F1h7yu1RABNisCd
jWq1x8/liFS0X1MPtHbjb9VVrgRNsemUrnIhGPTOG+iDWHk33vcftUulYtw1IZ14
tepArmR/duTU9v7J7GLbshjUO8hyPhDvF0TZKV+/290GQyrV4Mkd7kZJ0zU0OrJQ
Z1TiMne1e/RMWP/RNtpyOVif3hX71T3UeB28xo+HuElWd2jlZQQ1wh0JW7gZJzxD
p4Npl1elY1j4lGsXjPrXrBjMJ6X95XTIwsYLdtaSJlKXxvByec47dVSOhJZyfVHG
5UBsZZsAawS+bf6LFbNWH09MBwTZeS0K0i44Bf9ttiafkjSWCk4uJmhmkbGNOt49
DYRYRHykIik64t+9AFzW0SjHcPTsKjfGgCBwsws+UilSIZl5HNk=
=vT5l
-----END PGP SIGNATURE-----
Merge tag 'cxl-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
Pull compute express link (CXL) updates from Dave Jiang:
"The additions of note are adding CXL region remove support for locked
CXL decoders, adding unit testing support for XOR address translation,
and adding unit testing support for extended linear cache.
Misc:
- Remove incorrect page-allocator quirk section in documentation
- Remove unused devm_cxl_port_enumerate_dports() function
- Fix typo in cdat.c code comment
- Replace use of system_wq with system_percpu_wq
- Add locked CXL decoder support for region removal
- Return when generic target updated
- Rename region_res_match_cxl_range() to spa_maps_hpa()
- Clarify comment in spa_maps_hpa()
Enable unit testing for XOR address translation of SPA to DPA and vice versa:
- Refactor address translation funcs for testing in cxl_region
- Make the XOR calculations available for testing
- Add cxl_translate module for address translation testing in
cxl_test
Extended Linear Cache changes:
- Add extended linear cache size sysfs attribute
- Adjust failure emission of extended linear cache detection in
cxl_acpi
- Added extended linear cache unit testing support in cxl_test
Preparation refactor patches for PRM translation support:
- Simplify cxl_rd_ops allocation and handling
- Group xor arithmetric setup code in a single block
- Remove local variable @inc in cxl_port_setup_targets()"
* tag 'cxl-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: (22 commits)
cxl/test: Assign overflow_err_count from log->nr_overflow
cxl/test: Remove ret_limit race condition in mock_get_event()
cxl/test: remove unused mock function for cxl_rcd_component_reg_phys()
cxl/test: Add support for acpi extended linear cache
cxl/test: Add cxl_test CFMWS support for extended linear cache
cxl/test: Standardize CXL auto region size
cxl/region: Remove local variable @inc in cxl_port_setup_targets()
cxl/acpi: Group xor arithmetric setup code in a single block
cxl: Simplify cxl_rd_ops allocation and handling
cxl: Clarify comment in spa_maps_hpa()
cxl: Rename region_res_match_cxl_range() to spa_maps_hpa()
acpi/hmat: Return when generic target is updated
cxl: Add handling of locked CXL decoder
cxl/region: Add support to indicate region has extended linear cache
cxl: Adjust extended linear cache failure emission in cxl_acpi
cxl/test: Add cxl_translate module for address translation testing
cxl/acpi: Make the XOR calculations available for testing
cxl/region: Refactor address translation funcs for testing
cxl/pci: replace use of system_wq with system_percpu_wq
cxl: fix typos in cdat.c comments
...
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEEgMe7l+5h9hnxdsnuWYigwDrT+vwFAmkwoyoUHGJoZWxnYWFz
QGdvb2dsZS5jb20ACgkQWYigwDrT+vztdBAAjvZO0NOafCbhn6lUAz/T4VxPY0R7
L5RqeLci33rQzbQ0yhJYXsd8VemMo6Zk0qmlSwjddlOMPboHoC1jK3i4C16QoP+3
R5ecab0VoImLl2Ffig0BZoHQpVq01q2kTGQ2YyrryzDCgBCsBG3U10ZD380pGsTW
ypqEgOCxaQCq2mtqr5CavaCcquq2krrnHkkVQOP1ryWzRq1C3wDXcQXFYNdzXpDP
Lq8pBIh8WN5pYwrqjrFMrtNhj7BHPmowLEaAbNIWmH8WjGav624XcKq2O+arx3Hl
BDHFKVjWtiYikrWmAODZhlY3HgEj546h2HtQYwWPOKuSKkgzNVn28LFIDgL3oXDP
sJ6gWIDWMgRpEI6VzmqzRXJWbTAkIrRfHv3QFzvATSZV7eHk3eUpMZtG/qOi5z3P
rPwW7NSXKbPg5qi+zKpqC20Im1Wm6fF4qQtim3uNlz2KXlVGvQl5/Ww27nIZMn6B
Kkv5RGzdodePbKGqd+CADAQoJOpR6kOng5ZaRdZx+6aTTooyM7KSk8bFq7j/CoYM
PzVtO6IHIvV42di7H/NP8/qtQA3xwSLue3lWpTh+tzYmZvCdldZiIvBo9YXnlsEM
kCetDIGBxUWBj7OdYK4hC1BPBVw3XtCWM/51ElslDZTPvT543lApBfMnVTv3JmFp
gzvZ7XfZx443JOg=
=qSzr
-----END PGP SIGNATURE-----
Merge tag 'pci-v6.19-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
Pull PCI updates from Bjorn Helgaas:
"Enumeration:
- Enable host bridge emulation for PCI_DOMAINS_GENERIC platforms (Dan
Williams)
- Switch vmd from custom domain number allocator to the common
allocator to prevent a potential race with new non-VMD buses (Dan
Williams)
- Enable Precision Time Measurement (PTM) only if device advertises
support for a relevant role, to prevent invalid PTM Requests that
cause ACS violations that are reported as AER Uncorrectable
Non-Fatal errors (Mika Westerberg)
Resource management:
- Prevent resource tree corruption when BAR resize fails (Ilpo
Järvinen)
- Restore BARs to the original size if a BAR resize fails (Ilpo
Järvinen)
- Remove BAR release from BAR resize attempts by the xe, i915, and
amdgpu drivers so the PCI core can restore BARs if the resize fails
(Ilpo Järvinen)
- Move Resizable BAR code to rebar.c (Ilpo Järvinen)
- Add pci_rebar_size_supported() and use it in i915 and xe (Ilpo
Järvinen)
- Add pci_rebar_get_max_size() and use it in xe and amdgpu (Ilpo
Järvinen)
Power management and error handling:
- For drivers using PCI legacy suspend, save config state at suspend
so that state (not any earlier state from enumeration, probe, or
error recovery) will be restored when resuming (Lukas Wunner)
- For devices with no driver or a driver that lacks power management,
save config state at hibernate so that state (not any earlier state
from enumeration, probe, or error recovery) will be restored when
resuming (Lukas Wunner)
- Save device config space on device addition, before driver binding,
so error recovery works more reliably (Lukas Wunner)
- Drop pci_save_state() from several drivers that no longer need it
since the PCI core always does it and pci_restore_state() no longer
invalidates the saved state (Lukas Wunner)
- Document use of pci_save_state() by drivers to capture the state
they want restored during error recovery (Lukas Wunner)
Power control:
- Add a struct pci_ops.assert_perst() function pointer to
assert/deassert PCIe PERST# and implement it for the qcom driver
(Krishna Chaitanya Chundru)
- Add DT binding and pwrctrl driver for the Toshiba TC9563 PCIe
switch, which must be held in reset after poweron so the pwrctrl
driver can configure the switch via I2C before bringing up the
links (Krishna Chaitanya Chundru)
Endpoint framework:
- Convert the endpoint doorbell test to use a threaded IRQ to fix a
'sleeping while atomic' issue (Bhanu Seshu Kumar Valluri)
- Add endpoint VNTB MSI doorbell support to reduce latency between
host and endpoint (Frank Li)
New native PCIe controller drivers:
- Add CIX Sky1 host controller DT binding and driver (Hans Zhang)
- Add NXP S32G host controller DT binding and driver (Vincent
Guittot)
- Add Renesas RZ/G3S host controller DT binding and driver (Claudiu
Beznea)
- Add SpacemiT K1 host controller DT binding and driver (Alex Elder)
Amlogic Meson PCIe controller driver:
- Update DT binding to name DBI region 'dbi', not 'elbi', and update
driver to support both (Manivannan Sadhasivam)
Apple PCIe controller driver:
- Move struct pci_host_bridge allocation from pci_host_common_init()
to callers, which significantly simplifies pcie-apple (Marc
Zyngier)
Broadcom STB PCIe controller driver:
- Disable advertising ASPM L0s support correctly (Jim Quinlan)
- Add a panic/die handler to print diagnostic info in case PCIe
caused an unrecoverable abort (Jim Quinlan)
Cadence PCIe controller driver:
- Add module support for Cadence platform host and endpoint
controller driver (Manikandan K Pillai)
- Split headers into 'legacy' (LGA) and 'high perf' (HPA) to prepare
for new CIX Sky1 driver (Manikandan K Pillai)
MediaTek PCIe controller driver:
- Convert DT binding to YAML schema (Christian Marangi)
- Add Airoha AN7583 DT compatible and driver support (Christian
Marangi)
Qualcomm PCIe controller driver:
- Add Qualcomm Kaanapali to SM8550 DT binding (Qiang Yu)
- Add required 'power-domains' and 'resets' to qcom sa8775p, sc7280,
sc8280xp, sm8150, sm8250, sm8350, sm8450, sm8550, x1e80100 DT
schemas (Krzysztof Kozlowski)
- Look up OPP using both frequency and data rate (not just frequency)
so RPMh votes can account for both (Krishna Chaitanya Chundru)
Rockchip DesignWare PCIe controller driver:
- Add Rockchip RK3528 compatible strings in DT binding (Yao Zi)
STMicroelectronics STM32MP25 PCIe controller driver:
- Fix a race between link training and endpoint register
initialization (Christian Bruel)
- Align endpoint allocations to match the ATU requirements (Christian
Bruel)
Synopsys DesignWare PCIe controller driver:
- Clear L1 PM Substate Capability 'Supported' bits unless glue driver
says it's supported, which prevents users from enabling non-working
L1SS. Currently only qcom and tegra194 support L1SS (Bjorn Helgaas)
- Remove now-superfluous L1SS disable code from tegra194 (Bjorn
Helgaas)
- Configure L1SS support in dw-rockchip when DT says
'supports-clkreq' (Shawn Lin)
TI Keystone PCIe controller driver:
- Fail the probe instead of silently succeeding if ks_pcie_of_data
didn't specify Root Complex or Endpoint mode (Siddharth Vadapalli)
- Make keystone buildable as a loadable module, except on ARM32 where
hook_fault_code() is __init (Siddharth Vadapalli)"
* tag 'pci-v6.19-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: (100 commits)
MAINTAINERS: Add Manivannan Sadhasivam as PCI/pwrctrl maintainer
MAINTAINERS: Add CIX Sky1 PCIe controller driver maintainer
PCI: sky1: Add PCIe host support for CIX Sky1
dt-bindings: PCI: Add CIX Sky1 PCIe Root Complex bindings
PCI: cadence: Add support for High Perf Architecture (HPA) controller
MAINTAINERS: Add NXP S32G PCIe controller driver maintainer
PCI: s32g: Add NXP S32G PCIe controller driver (RC)
PCI: dwc: Add register and bitfield definitions
dt-bindings: PCI: s32g: Add NXP S32G PCIe controller
PCI: Add Renesas RZ/G3S host controller driver
PCI: host-generic: Move bridge allocation outside of pci_host_common_init()
dt-bindings: PCI: Add Renesas RZ/G3S PCIe controller binding
PCI: Validate pci_rebar_size_supported() input
Documentation: PCI: Amend error recovery doc with pci_save_state() rules
treewide: Drop pci_save_state() after pci_restore_state()
PCI/ERR: Ensure error recoverability at all times
PCI/PM: Stop needlessly clearing state_saved on enumeration and thaw
PCI/PM: Reinstate clearing state_saved in legacy and !PM codepaths
PCI: dw-rockchip: Configure L1SS support
PCI: tegra194: Remove unnecessary L1SS disable code
...
- Parse SMBIOS tables in memory directly on Macbooks that do not
implement the EFI SMBIOS protocol
- Obtain EDID information from the primary display while running in the
EFI stub, and expose it via bootparams on x86 (generic method is in
the works, and will likely land during the next cycle)
- Bring CPER handling for ARM systems up to data with the latest EFI
spec changes.
- Various cosmetic changes.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQQm/3uucuRGn1Dmh0wbglWLn0tXAUCaS6z+QAKCRAwbglWLn0t
XCs8AQCL2Ebzq/FzMB0DEzcqwp9GV6upRReqBIrZcFQuZ+8IcQD/V+N4u3h1m1nJ
ofl4KQckZTPPV+iwDDUb7scn5fwgpA4=
=2tk+
-----END PGP SIGNATURE-----
Merge tag 'efi-next-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI updates from Ard Biesheuvel:
"The usual trickle of EFI contributions:
- Parse SMBIOS tables in memory directly on Macbooks that do not
implement the EFI SMBIOS protocol
- Obtain EDID information from the primary display while running in
the EFI stub, and expose it via bootparams on x86 (generic method
is in the works, and will likely land during the next cycle)
- Bring CPER handling for ARM systems up to data with the latest EFI
spec changes
- Various cosmetic changes"
* tag 'efi-next-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
docs: efi: add CPER functions to driver-api
efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
efi/cper: Add a new helper function to print bitmasks
efi/cper: Adjust infopfx size to accept an extra space
RAS: Report all ARM processor CPER information to userspace
efi/libstub: x86: Store EDID in boot_params
efi/libstub: gop: Add support for reading EDID
efi/libstub: gop: Initialize screen_info in helper function
efi/libstub: gop: Find GOP handle instead of GOP data
efi: Fix trailing whitespace in header file
efi/memattr: Convert efi_memattr_init() return type to void
efi: stmm: fix kernel-doc "bad line" warnings
efi/riscv: Remove the useless failure return message print
efistub/x86: Add fallback for SMBIOS record lookup
DT bindings:
- Convert lattice,ice40-fpga-mgr, apm,xgene-storm-dma, brcm,sr-thermal,
amazon,al-thermal, brcm,ocotp, mt8173-mdp, Actions Owl SPS, Marvell
AP80x System Controller, Marvell CP110 System Controller,
cznic,moxtet, and apm,xgene-slimpro-mbox to DT schema format
- Add i.MX95 fsl,irqsteer, MT8365 Mali Bifrost GPU, Anvo ANV32C81W
EEPROM, and Microchip pic64gx PLIC
- Add missing LGE, AMD Seattle, and APM X-Gene SoC platform compatibles
- Updates to brcm,bcm2836-l1-intc, brcm,bcm2835-hvs, and bcm2711-hdmi
bindings to fix warnings on BCM2712 platforms
- Drop obsolete db8500-thermal.txt
- Treewide clean-up of extra blank lines and inconsistent quoting
- Ensure all .dtbo targets are applied to a base .dtb
- Speed up dt_binding_check by skipping running validation on empty
examples
DT core:
- Add of_machine_device_match() and of_machine_get_match_data() helpers
and convert users treewide
- Fix bounds checking of address properties in FDT code. Rework the code
to have a single implementation of the bounds checks.
- Rework of_irq_init() to ignore any implicit interrupt-parent (i.e. in
a parent node) on nodes without an interrupt. This matches the spec
description and fixes some RISC-V platforms.
- Avoid a spurious message on overlay removal
- Skip DT kunit tests on RISCV+ACPI
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEktVUI4SxYhzZyEuo+vtdtY28YcMFAmkwYp0ACgkQ+vtdtY28
YcMS1g/+Mr3pzojHKUEClu3hglNEw1Bvl/rD07s5q+f4d2eayXtRJVBDgKIwYciT
rROXLV9m0Ko2RGiRLHAeB/h4Jjd8NXzLM0GA0YvoHSgtk77xLCuzK5ZEW3o6EoYW
DWVHyoMHDNRRC0Iu+CaS6XId1DrtbV6Wc/oLYvoSJvpdsW9EYOksfrtKQAYU9X5p
/x5XKO4h8RIQTBmg/kjvJLUV6+7cJvOnkF/JkDyh+xOHrIJzQp/bJwcKiU3hGlhX
nGFtjmItNDsFGvR1CtDzUobEE/wgI3xCQHUmufInSNPB7VGw3hbp0nvaQ6htPQQQ
NOA1Q7lXJtqChUZx7OAHk64TQHhVlmJJoy0zCueTgRyjXU0nWb/id2Hn16k96FRh
3YCGArTBFlRriHuCj0fsZ618cLEN2nZCzqSf34HVjs30iP7oLauEJ+WgmfH491TB
eq60Vlwomxq60/hWqCdY1NTCo/zbfYUE+exry69NcL5KSZBN2WGwLPZUgVvYhNO3
dhSgAg+06ib7uq0LLUiokQXaByEEFJt2TxIjp9IDAqkPnvQmDverKL5DZUBHIYxw
E/89Pmm77DagdcIhMocbsdoH5Qu4qH8pdhfR3PL+Ma9drRLxmk3MpiT52VJZem0S
iXHb6fyfQzQ/WJcA4sKapa8EMZRm/9U/pVDx1msDmHfB8pbDEi0=
=ZM/+
-----END PGP SIGNATURE-----
Merge tag 'devicetree-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree updates from Rob Herring:
"DT bindings:
- Convert lattice,ice40-fpga-mgr, apm,xgene-storm-dma,
brcm,sr-thermal, amazon,al-thermal, brcm,ocotp, mt8173-mdp, Actions
Owl SPS, Marvell AP80x System Controller, Marvell CP110 System
Controller, cznic,moxtet, and apm,xgene-slimpro-mbox to DT schema
format
- Add i.MX95 fsl,irqsteer, MT8365 Mali Bifrost GPU, Anvo ANV32C81W
EEPROM, and Microchip pic64gx PLIC
- Add missing LGE, AMD Seattle, and APM X-Gene SoC platform
compatibles
- Updates to brcm,bcm2836-l1-intc, brcm,bcm2835-hvs, and bcm2711-hdmi
bindings to fix warnings on BCM2712 platforms
- Drop obsolete db8500-thermal.txt
- Treewide clean-up of extra blank lines and inconsistent quoting
- Ensure all .dtbo targets are applied to a base .dtb
- Speed up dt_binding_check by skipping running validation on empty
examples
DT core:
- Add of_machine_device_match() and of_machine_get_match_data()
helpers and convert users treewide
- Fix bounds checking of address properties in FDT code. Rework the
code to have a single implementation of the bounds checks.
- Rework of_irq_init() to ignore any implicit interrupt-parent (i.e.
in a parent node) on nodes without an interrupt. This matches the
spec description and fixes some RISC-V platforms.
- Avoid a spurious message on overlay removal
- Skip DT kunit tests on RISCV+ACPI"
* tag 'devicetree-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (55 commits)
dt-bindings: kbuild: Skip validating empty examples
dt-bindings: interrupt-controller: brcm,bcm2836-l1-intc: Drop interrupt-controller requirement
dt-bindings: display: Fix brcm,bcm2835-hvs bindings for BCM2712
dt-bindings: display: bcm2711-hdmi: Add interrupt details for BCM2712
of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root node
soc: tegra: Simplify with of_machine_device_match()
soc: qcom: ubwc: Simplify with of_machine_get_match_data()
powercap: dtpm: Simplify with of_machine_get_match_data()
platform: surface: Simplify with of_machine_get_match_data()
irqchip/atmel-aic: Simplify with of_machine_get_match_data()
firmware: qcom: scm: Simplify with of_machine_device_match()
cpuidle: big_little: Simplify with of_machine_device_match()
cpufreq: sun50i: Simplify with of_machine_device_match()
cpufreq: mediatek: Simplify with of_machine_get_match_data()
cpufreq: dt-platdev: Simplify with of_machine_get_match_data()
of: Add wrappers to match root node with OF device ID tables
dt-bindings: eeprom: at25: Add Anvo ANV32C81W
of/reserved_mem: Simplify the logic of __reserved_mem_alloc_size()
of/reserved_mem: Simplify the logic of fdt_scan_reserved_mem_reg_nodes()
of/reserved_mem: Simplify the logic of __reserved_mem_reserve_reg()
...
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEL65usyKPHcrRDEicpmLzj2vtYEkFAmku8DAACgkQpmLzj2vt
YEk1oQ/+PTkkVxeXaSMuC5/xLPuvDOwOt6w9bN5RbUaqGhg15x67clZ8Ibi6nXYt
cYxXR8rWMHFGujBdiP1UXRbYAAJEHnzYHAj2AQKFhPmSpeIm39TOcN2qEtSsYQ0r
mgcNi/9SAf+M3iF/b5qmcPgnfqZ3SB8jt1AFMV6F5Mbv+9y5ZYLbCDDD6TylJOGM
IU3VRt9B1ffSyc93SZkODXRNNGR/Iv0/0Yn1bPtNNSZeZ6ZNgrRPUukg0P+PsllY
W/hAhuoISKW1oSojlSeF4x5BJR/Xt0Mym7/IdraBbgPJPCwIBxfxcatQiSFJlaMD
GRFf0V1xD9gWxY/xNkmtjJhUjh6hmL6hTTX6lUVA+ltXKnUl7mfnFuMOt1naWKU+
hRech8eFRxJ4ZfwYTpT6w8IXV1OI0MGhcL7uWmbhpPGDGRTxQOqQE5DFTBrf54GB
OMlT0soDbyYQmCzZXaQyrn3HhCKpovmgjJRTMBvY1aQ6T707V/qu8C4eGNqlPjUn
4ywxwPaJ6B4M2q/nSl1BQPakka47pTVZoLkmsJuDU2npskPOs9ZHvfUXgMs7eOri
jS3BFoBOkrNAZ6YTiFtwjV0fw3CNHbSeicXV/fd1B3tB48NA52XBjq/uKiwOkZAJ
3bcJ5K7fgJXwOkVTAQhfgCPplfI1bbdvei40gkyITP36Ye3IyxE=
=7Jr3
-----END PGP SIGNATURE-----
Merge tag 'hid-for-linus-2025120201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID updates from Jiri Kosina:
- Proper mapping of HID_GD_Z to ABS_DISTANCE for stylus/pen types of
devices (Ping Cheng)
- Power management/hibernation improvements in intel-ish (Zhang Lixu)
- Improved support for several Logitech devices, e.g. G Pro X
Superlight 2, new iteration of Lighspeed receiver, G13, G510 (Nathan
Rossi, Mavroudis Chatzilazaridis, Leo L Schwab, Hans de Goede)
- Support for UcLogic XP-PEN Artist 24 Pro (Joshua Goins)
- WinWing Orion2 throttle support improvement (Ivan Gorinov)
- other assorted small fixes and device ID additions
* tag 'hid-for-linus-2025120201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: (37 commits)
drivers: hid: renegotiate resolution multipliers with device after reset
HID: evision: Fix Report Descriptor for Evision Wireless Receiver 320f:226f
HID: logitech-dj: Fix probe failure when used with KVM
HID: logitech-dj: Remove duplicate error logging
HID: logitech-dj: Add support for G Pro X Superlight 2 receiver
selftests/hid-tablet: add ABS_DISTANCE test for stylus/pen
HID: input: map HID_GD_Z to ABS_DISTANCE for stylus/pen
HID: bpf: fix typo in HID usage table
HID: bpf: add the Huion Kamvas 27 Pro
HID: bpf: add heuristics to the Huion Inspiroy 2S eraser button
HID: bpf: Add support for XP-Pen Deco02
HID: bpf: Add support for the XP-Pen Deco 01 V3
HID: bpf: Add support for the Waltop Batteryless Tablet
HID: bpf: Add fixup for Logitech SpaceNavigator variants
HID: bpf: support for Huion Kamvas 16 Gen 3
HID: bpf: add support for Huion Kamvas 13 (Gen 3) (model GS1333)
HID: bpf: Add support for the Inspiroy 2M
Documentation: hid-alps: Format DataByte* subsection headings
Documentation: hid-alps: Fix packet format section headings
HID: nintendo: add WQ_PERCPU to alloc_workqueue users
...
* Add support for Awinic AW99706 backlight driver.
* Add GPIOLIB dependency to backlight ktd2801 driver.
* Add devlink to LED Backlight's supplier LEDs to enforce correct removal
order and prevent NULL pointer dereferences.
* Fix kernel-doc warnings in lp855x.h
* Do not include <linux/fb.h> in backlight.h.
* Fix unused function warnings from suspend/resume ops in aw99706.c by
switching to DEFINE_SIMPLE_DEV_PM_OPS and using pm_ptr().
* Add Awinic AW99706 backlight binding to MAINTAINERS.
* Add Awinic AW99706 backlight binding documentation.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmkxtz4ACgkQUa+KL4f8
d2FYoQ//T/M/Vd+6HSuGSnICrPY7CGXwheE1xfg8hhVB9Sa5+LL8Tt4RTJ1BRNzT
B7VromDCPkPI7dAfYL7G0dFTu1kU3nN2Xl+86CjvsXsc7gy+8ftpePvUYJbUdhTl
w4K8sslvcCyMhGHm7U9TwFNDE6+ousrDLADJCo0Tf+tJhmy2IFcl5Sjgt5Y0RnMt
TmSOAXirbCvVJ8eIQSVPm5geCrSCJ7nxh1WRTKI6BMZsazvxAG1KzShKF0xE0xN3
SUurIJydxyw6qiNIwYlqph0h0151shILtELsN2/guegqN9RZTHTAFKa8kcrXMJS+
oGooIZh6B+IkLotv0T3v8LugX3kIi/jvevWffIak3AjHy4zSMhpDXZ0QhVDnMfzT
ueeNBpyqMeGwbkCirn2iZmlwMUIMS7AYhluBkq6HAmdO++GwSkqficypTPbyxCh7
M/DPZaFF0aJ4JOIyWDY5Pk2Fc+owsKWf2DurXhSZ7mHgzHgrY5NTEzG1q4esrPXj
r1mNxSP2CegE6S1XIp3fa96SM2VWnZYvW2ZGIfLHkwqnwOT4dqp8BvEVj7+3jt9x
5awFLVBjxEf4kUOKfF6ztRQfsJaeN+ujobHcP9wsGmEMWvA2ZH9+Z24SlrbsyfRT
kunwxRK9CDVw+l1e7JLWZG0wGbEck25n3Qt4opY+jnSX2SdvnXI=
=n4gn
-----END PGP SIGNATURE-----
Merge tag 'backlight-next-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
Pull backlight updates from Lee Jones:
"Additions:
- Add support for Awinic AW99706 backlight driver
Fixes:
- Add GPIOLIB dependency to backlight ktd2801 driver
- Add devlink to LED Backlight's supplier LEDs to enforce correct
removal order and prevent NULL pointer dereferences
- Fix kernel-doc warnings in lp855x.h
Removals:
- Do not include <linux/fb.h> in backlight.h
- Fix unused function warnings from suspend/resume ops in aw99706.c
by switching to DEFINE_SIMPLE_DEV_PM_OPS and using pm_ptr()
Bindings:
- Add Awinic AW99706 backlight binding to MAINTAINERS
- Add Awinic AW99706 backlight binding documentation"
* tag 'backlight-next-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight:
backlight: aw99706: Fix unused function warnings from suspend/resume ops
backlight: lp855x: Fix lp855x.h kernel-doc warnings
dt-bindings: leds: backlight: Add Awinic AW99706 backlight
backlight: aw99706: Add support for Awinic AW99706 backlight
backlight: led-bl: Add devlink to supplier LEDs
backlight: ktd2801: Depend on GPIOLIB
backlight: Do not include <linux/fb.h> in header file
* Add optional GPIO enable pin support to PWM LED driver.
* Allow LED module 0 to be added to module bank in lp50xx driver.
* Fix upboard LED driver module alias to ensure proper auto-loading.
* Update LP5009 to support 3 modules for a total of 9 LEDs.
* Skip LEDs without color components in cros_ec driver instead of failing probe.
* Fix GPIO descriptor leaks in netxbig error paths by releasing acquired GPIOs.
* Allow LED_COLOR_ID_MULTI in qcom-lpg driver for greater flexibility.
* Enable LP55XX common LED use without FW_LOADER_USER_HELPER.
* Ensure lp50xx chip is enabled before any I2C communication.
* Use fwnode_for_each_child_node() instead of fwnode_for_each_available_child_node()
in LED drivers.
* Use device_get_next_child_node() instead of fwnode_get_next_available_child_node()
in LED flash drivers.
* Replace sprintf() with sysfs_emit() in sysfs show functions for improved
bounds checking.
* Replace system_wq() with system_percpu_wq() in the input event trigger.
* Reorder include files to alphabetic order in the PWM LED driver.
* Do not enable TRILED in qcom-lpg when configuring PWM.
* Drop duplicate LEDS_EXPRESSWIRE config from Kconfig.
* Remove arcxcnn_bl.txt Device Tree binding documentation.
* Convert ArcticSand arc2c0608 LED driver binding to DT Schema.
* Add default-brightness property to common LED binding.
* Add enable-gpios property to PWM LED binding.
* Add PM7550 to qcom,spmi-flash-led compatible.
* Explain standalone PWM usage in qcom-lpg binding.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmkxtx8ACgkQUa+KL4f8
d2EsAA/+KdtCs9WXrFcQOHZBlZvLeNMklninXPjMFOMcjd6A9l26XzkKW5qS59ax
1H+gUxjryN5EGtYE1ITKjpwwWJL+VEGsMXcuonMf0g/UwE5CFw3VR1nL3+xK9IM0
2xzTZwDkbqYUVsEWVparazdvVU/niwqdjyWqfYFM3XXZWk5TpFkzOnluRwSPAt70
IZRJzYPHlGiZKmFpLtmxFcsJM7MiqsHgP3tzMEAmUHFQg75MhWVUJld8hTaek6hf
gS+jqdoCV6+dnP76KlRZ2OMHwAG/Nmu91mFp5VnG8vIH6PhERokP6ewi07lJUPTp
bHyb/oWb+YJvAXnzZ5Yh5q7ygnAa2kFgYAmUBDQyvTwmOgloMl7qb1hzSOqfRkE0
xyQ8ah6gtTu6Tq0kBB3jV9UFfG1ecDjRVqIbJnEFZjOfb3peyjdNVjgMraBWGCHB
D93RAft/aByE3bnX20DF2icOGJDmlAVaHPETO8yMBVIKfynjY3y8eTdt126pT7a8
HOs8UtJZXmwHdgtvgUzAOiklxvuYMKIBqkym8BQ20lCnqw+BKxqQ962+rGJhrxOj
AKy4gx980HmBxaet4ssn5ba186+jlCR26WFPRAcHF17c8+aKPXH8htdPFZPWAd1Z
MoQP/VOHzsPE4x75xvVX9DkZiv9WyHxaCzxlXXZhAHiYxoLg4uE=
=/TDJ
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"Updates:
- Add optional GPIO enable pin support to PWM LED driver
Fixes:
- Allow LED module 0 to be added to module bank in lp50xx driver
- Fix upboard LED driver module alias to ensure proper auto-loading
- Update LP5009 to support 3 modules for a total of 9 LEDs
- Skip LEDs without color components in cros_ec driver instead of
failing probe
- Fix GPIO descriptor leaks in netxbig error paths by releasing
acquired GPIOs
- Allow LED_COLOR_ID_MULTI in qcom-lpg driver for greater flexibility
- Enable LP55XX common LED use without FW_LOADER_USER_HELPER
- Ensure lp50xx chip is enabled before any I2C communication
Cleanups:
- Use fwnode_for_each_child_node() instead of
fwnode_for_each_available_child_node() in LED drivers
- Use device_get_next_child_node() instead of
fwnode_get_next_available_child_node() in LED flash drivers
- Replace sprintf() with sysfs_emit() in sysfs show functions for
improved bounds checking
- Replace system_wq() with system_percpu_wq() in the input event
trigger
- Reorder include files to alphabetic order in the PWM LED driver
- Do not enable TRILED in qcom-lpg when configuring PWM
- Drop duplicate LEDS_EXPRESSWIRE config from Kconfig
Removals:
- Remove arcxcnn_bl.txt Device Tree binding documentation
Devicetree bindings:
- Convert ArcticSand arc2c0608 LED driver binding to DT Schema
- Add default-brightness property to common LED binding
- Add enable-gpios property to PWM LED binding
- Add PM7550 to qcom,spmi-flash-led compatible
- Explain standalone PWM usage in qcom-lpg binding"
* tag 'leds-next-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (21 commits)
leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM
dt-bindings: leds: qcom-lpg: Explain standalone PWM usage
leds: rgb: leds-qcom-lpg: Allow LED_COLOR_ID_MULTI
leds: pwm: Reorder include files to alphabetic order
leds: pwm: Add optional GPIO enable pin support
dt-bindings: leds: pwm: Add enable-gpios property
leds: trigger: Replace use of system_wq() with system_percpu_wq()
leds: led-class: Replace sprintf() with sysfs_emit() in sysfs show functions
dt-bindings: leds: qcom,spmi-flash-led: Add PM7550
leds: netxbig: Fix GPIO descriptor leak in error paths
leds: leds-lp50xx: Enable chip before any communication
leds: Drop duplicate LEDS_EXPRESSWIRE config
leds: leds-cros_ec: Skip LEDs without color components
leds: leds-lp50xx: LP5009 supports 3 modules for a total of 9 LEDs
leds: upboard: Fix module alias
leds: leds-lp50xx: Allow LED 0 to be added to module bank
leds: lp55xx_common: Enable use without FW_LOADER_USER_HELPER
dt-bindings: leds: Add default-brightness property to common.yaml
leds: flash: Use fwnode_get_next_child_node() instead
leds: Use fwnode_for_each_child_node() instead
...
* Add Core, Regulator, Onkey and Battery Charger support for the NXP PF1550
Power Management IC (PMIC).
* Introduce __SMC_KEY macro to fix GCC 15.2.1 errors in macsmc.
* Add board definitions for TQMxCU1-HPCM and TQMxCU2-HPCM to the tqmx86 driver.
* Add support for Broadcom BCM2712 SoC to the bcm2835-pm driver.
* Hook up the qnap-mcu-eeprom sub-device to qnap-mcu.
* Enable compile testing for the Altera SOCFPGA System Manager driver.
* Fix device reference leak in altr_sysmgr_regmap_lookup_by_phandle().
* Reserve the unused second I2C address for DA9063 to prevent userspace
interference.
* Fix resource leak in da9055_device_init() by calling regmap_del_irq_chip()
in the error path.
* Fix potential IRQ chip conflict when probing multiple MAX77620 devices by
using devm_kmemdup for regmap_irq_chip.
* Return -EPROBE_DEFER when a syscon devuice is not found to allow deferred
probing.
* Update email address for the PF1550 PMIC driver in MAINTAINERS.
* Correct file entry for PF1550 MFD driver in MAINTAINERS from pfd1550.h to
pf1550.h.
* Calculate checksum on the actual number of received bytes in qnap-mcu for
error messages.
* Use -EPROTO instead of -EIO for checksum errors in qnap-mcu.
* Add proper error handling for command errors (e.g., "@8", "@9") in qnap-mcu.
* Fix missing irq_domain_remove() in error path of mt63{58,97}_irq_init().
* Mark SMC write buffer arguments as const in apple_smc_write(), apple_smc_rw(),
and apple_smc_write_atomic().
* Simplify the error handling path in da9055_device_init() by removing a
redundant mfd_remove_devices() call.
* Use regmap_reg_range() and a real one-element array for pmic_status_range in
rohm-bd718x7 for cleaner initialization.
* Remove select I2C_K1 from MFD_SPACEMIT_P1 to avoid build failures when
I2C_K1's dependencies are disabled.
* Remove unneeded semicolon from ls2k_bmc_recover_pci_data().
* Drop OF dependency for MFD_MAX5970 in Kconfig to allow wider compile testing
and non-OF systems.
* Make OF ID table style consistent in simple-mfd-i2c driver.
* Update header inclusions in simple-mfd-i2c to follow IWYU (Include What You
Use) principle.
* Move checksum verification logic to a separate function in qnap-mcu.
* Use chained IRQs for S2MPG10 in the Samsung SEC driver to simplify interrupt
handling.
* Drop a stray semicolon from sec-irq.c.
* Remove the unused TI WL1273 FM radio core driver.
* Remove the unused wl1273-core.h header and tidy up its reference in
documentation.
* Add Device Tree binding for the NXP PF1550 PMIC.
* Add missing GPIO pins and supply properties to the Silergy SY7636A PMIC
binding.
* Add interrupt-controller property to the Maxim MAX77705 binding for
sub-device interrupt source determination.
* Add Device Tree binding for the Renesas R2A11302FT PMIC.
* Allow the wakeup-source property in the Dialog DA9063 binding.
* Make interrupt-related properties optional in the TI TPS65910 PMIC binding.
* Document the Qualcomm PMIV0104 PMIC compatible string.
* Document the Qualcomm PM7550 PMIC compatible string.
* Enable power button subnode for TWL603x in the TI TWL binding.
* Convert the Dialog DA9052/53 I2C binding from .txt to .yaml format,
including compatible string fallback and interrupt properties.
* Document control-scb and sysreg-scb syscons on pic64gx with fallback
compatibles.
* Document sama7g5-sfrbu and sama7d65-sfrbu syscons with fallback to
atmel,sama5d2-sfrbu.
* Fix LEDs node schema in fsl,mc13xxx binding by adding led@ child nodes and
missing properties.
* Add mt7981-topmisc compatible string to the syscon binding.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmkxtwoACgkQUa+KL4f8
d2GiAw/9Ewvlpm+p0Ac/CjxwTRgeM08OJv7xzni3kHtefOvU/0dVTkqJsm3235yc
SOO4zqCrpldUqAqLzycOmm1bDOMi3qCvmR/Es7gqhkskCHNZ9WDv3z6aZJEAo2g5
A6RHb5W8lHWc8BqyyyahDfX0D5sHerh03CCWitHkr49oCqzMMaRssVY5Wp1tzKb/
DYj+gCm8POLu5+0vuGm+I5t90mLOQA/MjHCVBMZ+4vtnXmre6w+fRWNSwGdqhTci
zsrPUuKUgOy3PvVhjugk4dPHEEwxaZuQ/Az41fpeb8qj0Y0XEaLv6g2/O3Sc8E/j
esyvbitg49noQCBWpefTUlWZjyxJivLIfIc2n3o+Tn+yWOVZ2+6AqXzhCYOqPeZw
sodep1W8uweI66+MF67zwTfNuplVLQrRMWbv/mhnvQLxnc8cllhboUUu6SFGQ8hP
phG5Zf1Gzmz3vJNGZRApwQnwj2nc7tY3FZdZnQW24gBU9tnrIH/LQyOEXoJsvRxC
AU/VoRA6Tbr1PGuyXJuqaxzkYCbTXUX294wMW9w1HZiXB2wLGDEItLm55pcjZEYI
ro3GRHW/7UjNg1Omwld5CuszNWFk06SSqBdP4XVJK5tpf02Rplk6EI6ftGH1zaoL
n7FRKsc7W5Xhky0bTGrtqxNkXodUEVCR45n+wlkJv6VM66m9WeU=
=2TS8
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"Updates:
- Add Core, Regulator, Onkey and Battery Charger support for the NXP
PF1550 Power Management IC (PMIC)
- Introduce __SMC_KEY macro to fix GCC 15.2.1 errors in macsmc
- Add board definitions for TQMxCU1-HPCM and TQMxCU2-HPCM to the
tqmx86 driver
- Add support for Broadcom BCM2712 SoC to the bcm2835-pm driver
- Hook up the qnap-mcu-eeprom sub-device to qnap-mcu
Fixes:
- Enable compile testing for the Altera SOCFPGA System Manager driver
- Fix device reference leak in altr_sysmgr_regmap_lookup_by_phandle()
- Reserve the unused second I2C address for DA9063 to prevent
userspace interference
- Fix resource leak in da9055_device_init() by calling
regmap_del_irq_chip() in the error path
- Fix potential IRQ chip conflict when probing multiple MAX77620
devices by using devm_kmemdup for regmap_irq_chip
- Return -EPROBE_DEFER when a syscon devuice is not found to allow
deferred probing
- Update email address for the PF1550 PMIC driver in MAINTAINERS
- Correct file entry for PF1550 MFD driver in MAINTAINERS from
pfd1550.h to pf1550.h
- Calculate checksum on the actual number of received bytes in
qnap-mcu for error messages
- Use -EPROTO instead of -EIO for checksum errors in qnap-mcu
- Add proper error handling for command errors (e.g., "@8", "@9") in
qnap-mcu
- Fix missing irq_domain_remove() in error path of
mt63{58,97}_irq_init()
Cleanups:
- Mark SMC write buffer arguments as const in apple_smc_write(),
apple_smc_rw(), and apple_smc_write_atomic()
- Simplify the error handling path in da9055_device_init() by
removing a redundant mfd_remove_devices() call
- Use regmap_reg_range() and a real one-element array for
pmic_status_range in rohm-bd718x7 for cleaner initialization
- Remove select I2C_K1 from MFD_SPACEMIT_P1 to avoid build failures
when I2C_K1's dependencies are disabled
- Remove unneeded semicolon from ls2k_bmc_recover_pci_data()
- Drop OF dependency for MFD_MAX5970 in Kconfig to allow wider
compile testing and non-OF systems
- Make OF ID table style consistent in simple-mfd-i2c driver
- Update header inclusions in simple-mfd-i2c to follow IWYU (Include
What You Use) principle
- Move checksum verification logic to a separate function in qnap-mcu
- Use chained IRQs for S2MPG10 in the Samsung SEC driver to simplify
interrupt handling
- Drop a stray semicolon from sec-irq.c
Removals:
- Remove the unused TI WL1273 FM radio core driver
- Remove the unused wl1273-core.h header and tidy up its reference in
documentation
Device tree bindings:
- Add Device Tree binding for the NXP PF1550 PMIC
- Add missing GPIO pins and supply properties to the Silergy SY7636A
PMIC binding
- Add interrupt-controller property to the Maxim MAX77705 binding for
sub-device interrupt source determination
- Add Device Tree binding for the Renesas R2A11302FT PMIC
- Allow the wakeup-source property in the Dialog DA9063 binding
- Make interrupt-related properties optional in the TI TPS65910 PMIC
binding
- Document the Qualcomm PMIV0104 PMIC compatible string
- Document the Qualcomm PM7550 PMIC compatible string
- Enable power button subnode for TWL603x in the TI TWL binding
- Convert the Dialog DA9052/53 I2C binding from .txt to .yaml format,
including compatible string fallback and interrupt properties
- Document control-scb and sysreg-scb syscons on pic64gx with
fallback compatibles
- Document sama7g5-sfrbu and sama7d65-sfrbu syscons with fallback to
atmel,sama5d2-sfrbu
- Fix LEDs node schema in fsl,mc13xxx binding by adding led@ child
nodes and missing properties
- Add mt7981-topmisc compatible string to the syscon binding"
* tag 'mfd-next-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (42 commits)
mfd: sec: Drop a stray semicolon
mfd: qnap-mcu: Hook up the EEPROM sub-device
dt-bindings: mfd: syscon: Add mt7981-topmisc
dt-bindings: mfd: fsl,mc13xxx: Fix LEDs node schema
mfd: mt6358-irq: Fix missing irq_domain_remove() in error path
mfd: mt6397-irq: Fix missing irq_domain_remove() in error path
dt-bindings: mfd: Document syscons falling back to atmel,sama5d2-sfrbu
dt-bindings: mfd: Document control-scb and sysreg-scb on pic64gx
dt-bindings: mfd: Convert dlg,da9052-i2c.txt to yaml format
mfd: sec: Use chained IRQs for s2mpg10
mfd: qnap-mcu: Add proper error handling for command errors
mfd: qnap-mcu: Move checksum verification to its own function
mfd: qnap-mcu: Use EPROTO in stead of EIO on checksum errors
mfd: qnap-mcu: Calculate the checksum on the actual number of bytes received
mfd: simple-mfd-i2c: Don't use "proxy" headers
mfd: simple-mfd-i2c: Make ID table style consistent
mfd: Kconfig: Drop OF dependency on MFD_MAX5970
mfd: ls2kbmc: Remove unneeded semicolon from ls2k_bmc_recover_pci_data()
dt-bindings: mfd: twl: Enable power button also for TWL603X
MAINTAINERS: Adjust file entry in NXP PF1550 PMIC MFD DRIVER
...
- Allow more host caps to be modified through debugfs
- Skip to set the default 200mA SD current limit
MMC host:
- Convert a few more DT bindings to the DT schema
- dw_mmc: Add Shawn Lin as co-maintainer for the dw_mmc drivers
- dw_mmc-rockchip: Add memory clock auto-gating support
- dw_mmc-rockchip: Add support for the RK3506 variant
- meson-mx-sdio: Ignore disabled "mmc-slot" child-nodes
- meson-mx-sdio: Refactoring and general code improvements
- renesas_sdhi: Enable bigger data ports where available
- renesas_sdhi: Manage reset in probe and during system-wide suspend/resume
- sdhci-brcmstb: Add support for the BCM72116 and BCM74371 variants
- sdhci-brcmstb: Save/restore registers during system-wide suspend/resume
- sdhci-msm: Add support for the sm8750 and the Kaanapali variants
- sdhci-msm: Avoid early clock doubling during HS400 transition
- sdhci-of-dwcmshc: Add command queue support for Rockchip SOCs
- sdhci-of-dwcmshc: Add support for the Eswin EIC7700 variant
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmkutuAXHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCn30xAAqG+pVwtJLiAP26oKa43tvnHy
fwJRCKxLuh1S2JM95X5Q8E0bgFJfOoEM280DDZTxeJcVesIeZovLEVYfzGv53wkw
4QVbWrixzSww5PhGN25SbxswzqaYRuZt7BPeER2n1f5swgNAuHjnIAkOLw2sR7BF
gaCu/2/m5D0mgIQMUjmNe0bVYNWC1uuAI9GIamwKfbN+0tgwwruV6H6WUtvU+0wf
xXv3RC7R4kyI1fBG0CqC6MyGsdcj2mQC9WG92ZlS+V9vnY3wDcwnD8Kcb9IKehBH
sOBwPGpAPkTmvIwkmRaaiJzGHafdomCg73t7kLLeh642MKsmp/oN7XQwXxm6AM1j
WoCjA/cIAKjSI9vskjdd1LCUYs9Ja+b+LtrqfdcZvh1+MgpsJnpXIMm6npiwbqHv
MYnsLcx2NLfIU8jZnRePy5U/MCRvz5Ow5ADZDrwV2HQ31J7Y7FxHSN+lTPIWC7Fc
B4Gy6SPYIDQUP4aolEufbqE8UDqHXhZhVGGKKHPxpFWjkTfCRM99zsUONs9PBzrW
lkMMA6VKme2F66b2SDI65kZeFNUqtb+skmrzDnq3+v+SaPU14ToXBeY3dY42Ee15
nn4UcyGjQHh0wjQoeBI4gvkoiq9MIwJMmJwmxn3Z+NkrhO7V5ecrL7uMUGIYzxjY
YvDMdHmPmqjPZG8cQaU=
=Gf5H
-----END PGP SIGNATURE-----
Merge tag 'mmc-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC updates from Ulf Hansson:
"MMC core:
- Allow more host caps to be modified through debugfs
- Skip to set the default 200mA SD current limit
MMC host:
- Convert a few more DT bindings to the DT schema
- dw_mmc: Add Shawn Lin as co-maintainer for the dw_mmc drivers
- dw_mmc-rockchip:
- Add memory clock auto-gating support
- Add support for the RK3506 variant
- meson-mx-sdio:
- Ignore disabled "mmc-slot" child-nodes
- Refactoring and general code improvements
- renesas_sdhi:
- Enable bigger data ports where available
- Manage reset in probe and during system-wide suspend/resume
- sdhci-brcmstb:
- Add support for the BCM72116 and BCM74371 variants
- Save/restore registers during system-wide suspend/resume
- sdhci-msm:
- Add support for the sm8750 and the Kaanapali variants
- Avoid early clock doubling during HS400 transition
- sdhci-of-dwcmshc:
- Add command queue support for Rockchip SOCs
- Add support for the Eswin EIC7700 variant"
* tag 'mmc-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (40 commits)
mmc: sdhci-of-dwcmshc: reduce CIT for better performance
mmc: sdhci-of-dwcmshc: Disable internal clock auto gate for Rockchip SOCs
mmc: sdhci-msm: Avoid early clock doubling during HS400 transition
MAINTAINERS: Add Shawn Lin as co-maintainer for dw_mmc drivers
mmc: sdhci-of-dwcmshc: Fix command queue support for RK3576
mmc: renesas_sdhi: Add suspend/resume hooks
mmc: renesas_sdhi: Switch to SYSTEM_SLEEP_PM_OPS()/RUNTIME_PM_OPS() and pm_ptr()
mmc: renesas_sdhi: Deassert the reset signal on probe
dt-bindings: mmc: am654: Simplify dma-coherent property
mmc: meson-mx-sdio: Ignore disabled "mmc-slot" child-nodes
mmc: meson-mx-sdio: Fix indentation in meson_mx_mmc_irq_thread()
mmc: meson-mx-sdio: Use dev_err_probe() where appropriate
mmc: meson-mx-sdio: Use devm_mmc_alloc_host() helper
mmc: meson-mx-sdio: Refactor internal clock initialization
mmc: meson-mx-sdio: Use devm_clk_get_enabled()
mmc: meson-mx-sdio: Switch to regmap for register access
mmc: core: add WQ_PERCPU to alloc_workqueue users
mmc: dw_mmc-rockchip: Add memory clock auto-gating support
mmc: omap: add WQ_PERCPU to alloc_workqueue users
mmc: mtk-sd: replace use of system_wq with system_percpu_wq
...
- Allow power-off for out-of-band wakeup-capable devices
- Drop the redundant call to dev_pm_domain_detach() for the amba bus
- Extend the genpd governor for CPUs to account for IPIs
pmdomain providers:
- bcm: Add support for BCM2712
- mediatek: Add support for MFlexGraphics power domains
- mediatek: Add support for MT8196 power domains
- qcom: Add RPMh power domain support for Kaanapali
- rockchip: Add support for RV1126B
pmdomain consumers:
- usb: dwc3: Enable out of band wakeup for i.MX95
- usb: chipidea: Enable out of band wakeup for i.MX95
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmkt1HYXHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCk3PQ//W24ZdZ5cqXJASrw4YihTovbR
Pk/cVBacua32r3uBAf+GKdhAXrC7zaPbohp4tou5tpuY6I54NDJ4mpaTLUr+iZ6A
aiKGprBrNCNMU7Mu6Af23peQNo0t+0sdsxp3wjZAMcSK0/ioOnc2R+IZhjHI9dPh
Us7Ke/Pa1DRu78T0P2quRvIIRPv5iGep2vL8LFkQtPNS4tAU5ZHTWghVip+Q0m7x
660WwZ5a9Bkzii/mqxFlXnXMnFjaJwi7zEPEKEMKd88cTjZXZGqScq8Ojfxto4Jx
mdn9kPqwUR2QILTVKyBy2nJTeCB5nLvLhldi5/1nVxhqopN5ll4VwFx8CVsEPVTQ
l76IUMzdAmztnVqs1p7qZ8dyFKdYztNRSESapumpu10/DIIOgWW4eLNk5Sk+7d0K
1fZDL/hWV2j4gnY0wSjGht2JQ2jhDBsgkxInxvQY2a8Ik91gwyUsD7r3mCq/YwaA
97GJHk9YO75jolFPy6PniXttzVuoJXPEcvgpBR3br1iFRQhSoGIEfFcDnZEaH9Sw
m7nSc1Q99a6rsmq+WavB5JVPZBr2UkBhE6x+IU+MEBPwykjNj/1cZ7x4rtqzX666
eOn1FBDQ63CLEQl3hAPp1pxy3YB0nHcxKR9CPAZjECwZTfsYgJCrRNHyZb+yhPsU
qKKXXMaOyyowoLraGbQ=
=Fkue
-----END PGP SIGNATURE-----
Merge tag 'pmdomain-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm
Pull pmdomain updates from Ulf Hansson:
"pmdomain core:
- Allow power-off for out-of-band wakeup-capable devices
- Drop the redundant call to dev_pm_domain_detach() for the amba bus
- Extend the genpd governor for CPUs to account for IPIs
pmdomain providers:
- bcm: Add support for BCM2712
- mediatek: Add support for MFlexGraphics power domains
- mediatek: Add support for MT8196 power domains
- qcom: Add RPMh power domain support for Kaanapali
- rockchip: Add support for RV1126B
pmdomain consumers:
- usb: dwc3: Enable out of band wakeup for i.MX95
- usb: chipidea: Enable out of band wakeup for i.MX95"
* tag 'pmdomain-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: (26 commits)
pmdomain: Extend the genpd governor for CPUs to account for IPIs
smp: Introduce a helper function to check for pending IPIs
pmdomain: mediatek: convert from clk round_rate() to determine_rate()
amba: bus: Drop dev_pm_domain_detach() call
pmdomain: bcm: bcm2835-power: Prepare to support BCM2712
pmdomain: mediatek: mtk-mfg: select MAILBOX in Kconfig
pmdomain: mediatek: Add support for MFlexGraphics
pmdomain: mediatek: Fix build-errors
cpuidle: psci: Replace deprecated strcpy in psci_idle_init_cpu
pmdomain: rockchip: Add support for RV1126B
pmdomain: mediatek: Add support for MT8196 HFRPSYS power domains
pmdomain: mediatek: Add support for MT8196 SCPSYS power domains
pmdomain: mediatek: Add support for secure HWCCF infra power on
pmdomain: mediatek: Add support for Hardware Voter power domains
pmdomain: qcom: rpmhpd: Add RPMh power domain support for Kaanapali
usb: dwc3: imx8mp: Set out of band wakeup for i.MX95
usb: chipidea: ci_hdrc_imx: Set out of band wakeup for i.MX95
usb: chipidea: core: detach power domain for ci_hdrc platform device
pmdomain: core: Allow power-off for out-of-band wakeup-capable devices
PM: wakeup: Add out-of-band system wakeup support for devices
...
GPIO core:
- add proper support for shared GPIOs that's aiming to replace the
current sharing mechanism (which provides no synchronization ot enable
counting) and enable it for Qualcomm platforms
- improve the software node GPIO lookup by using the fwnode
representation instead of the software node's name which was prone to
bugs (GPIO controllers don't have to use the software node's name as
their kernel label)
- remove the last user of legacy-of-mm-gpiochip.h and drop the header
- move closer to removing the legacy gpio_request_one() routine
- rename some symbols for consistency
- shrink GPIO printk() helpers by reusing existing code
- remove some redundant kernel messages
- use min() instead of min_t() in GPIO ACPI code
- use system_percpu_wq instead of system_wq in GPIO character device code
New drivers:
- add a driver for the QIXIS FPGA GPIO controller
Driver improvements:
- use modernized variants of power management macros across a wide array
of drivers in order to avoid having to use the __maybe_unused attribute
- convert gpio-elkhartlake and reset-gpio to using the auxiliary bus
instead of the platform bus as they are not really described in
firmware
- use lock guards and update symbol prefixes in gpio-mmio
- support the bryx radio interface kit in gpio-mpsse + refactor the
driver
- use software nodes for configuring the reset-gpio driver, including
setting up the reference to the shared "reset" pin
- check and propagate the return value of gpiod_set_value() to user-space
in gpio-virtuser (this was previously not possible as this function
returned void)
- extend the gpio-regmap helper with more features (bypass cache for
aliased inputs, force writes for aliased data registers, add a new
configuration parameter)
- remove unneeded includes from gpio-aspeed and gpio-latch
- add support for Tegra410 to gpio-tegra186
- replace PCI-specific PM with generic device-level PM in gpio-bt8xx
- use dynamic GPIO range allocation in gpio-loongson-64bit
- improve handling of level-triggered interrupts in gpio-pca953x
- add suspend/resume support to gpio-fxl6408
- add support for more models to gpio-menz127
- optimize gpio-mvebu interrupt handling by avoiding unnecessary calls
to mvebu_gpio_irq_handler()
- make locking more consistent in gpio-grgpio
Device-tree bindings:
- document new NXP and Microchip models
Documentation:
- add a comprehensive compatibility and feature list for gpio-pca953x,
which is a great addition as it's probably the most commonly used GPIO
expander driver
- kernel-doc tweaks
Late fixes:
- use BYTE_CTRL_MODE for 2K2000/3000 models in gpio-loongson
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEkeUTLeW1Rh17omX8BZ0uy/82hMMFAmktpZkACgkQBZ0uy/82
hMPRNg/+PEhBT1Sm9GZDL2c3urSfEyIIA97nxvV6rad75Xfj8IVy+orvyhJHJgni
ksjlvLUQLYQ1j82TlCIZDlj3dAmk3rkb6wwbcUubOb7G/xkvWHQztrnmDk4bvSdr
0vR/dEGOUDRLJxPjeQdFzEoDqLrCqy5QwugH3hd6NASBy+n/g7j2Gb4Pc8IA14wL
ogkBlP8nXVv2w7GMFESjNldWvxFnOasGuzIfM7mIBDBSjLzEANcuH/E5dNXPFIO7
kNN8eSnSfMGH0Z0DjdU9tkaAiLypw9FHqSwU6JKNjE/nzzcGV3OzDMM2vgKLETin
z9tNPBtvXOSBuFbxydWUgX20AmNo5ZEfqGXCwinTHOLwABGZPigi7Ogwxeox0SZ4
OKm37GUtZlO+dJC8bWUA82l9CwM9GDcxn7/Fv4s4vLaULUfeZHXn1OP4JZ4WmuZi
J7D5lMIiXKI9EBH95AX3c/r5drZQh1T4Rr7GJ4GG9uceYGTzsE65idI0KXTT1mbx
nMfQYvNSHGk123rN1bLQov1jZE7foXE9mQ+MzMNSWI3C1WdCGRBorqN8+wMrBU29
OLS66UorNwSCIl0XY+lIgdiW6OXBTc65jF1v+EdSZaFknEYHQm9TIxQNH+tQDYfz
irl2dhxz/iaekxO7p516iY3NeqO9Af4SfITVmAX4xDvak3tcYsU=
=Mw+x
-----END PGP SIGNATURE-----
Merge tag 'gpio-updates-for-v6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio updates from Bartosz Golaszewski:
"There's one new driver, lots of various updates to existing ones, some
refactoring support for new models and misc tweaks and fixes.
The biggest new feature in GPIO core is adding support for managed,
enable-counted sharing of GPIO pins, something that - until now - was
only hacked around with the GPIOD_FLAGS_BIT_NONEXCLUSIVE request flag
which basically allowed drivers to "fight it out" for the descriptor
and provided no synchronization. It was enabled on Qualcomm platforms
(and thus is enabled on arm64 defconfig) and I plan on removing
GPIOD_FLAGS_BIT_NONEXCLUSIVE once all drivers using it are switched to
the new mechanism.
GPIO core:
- add proper support for shared GPIOs that's aiming to replace the
current sharing mechanism (which provides no synchronization ot
enable counting) and enable it for Qualcomm platforms
- improve the software node GPIO lookup by using the fwnode
representation instead of the software node's name which was prone
to bugs (GPIO controllers don't have to use the software node's
name as their kernel label)
- remove the last user of legacy-of-mm-gpiochip.h and drop the header
- move closer to removing the legacy gpio_request_one() routine
- rename some symbols for consistency
- shrink GPIO printk() helpers by reusing existing code
- remove some redundant kernel messages
- use min() instead of min_t() in GPIO ACPI code
- use system_percpu_wq instead of system_wq in GPIO character device
code
New drivers:
- add a driver for the QIXIS FPGA GPIO controller
Driver improvements:
- use modernized variants of power management macros across a wide
array of drivers in order to avoid having to use the __maybe_unused
attribute
- convert gpio-elkhartlake and reset-gpio to using the auxiliary bus
instead of the platform bus as they are not really described in
firmware
- use lock guards and update symbol prefixes in gpio-mmio
- support the bryx radio interface kit in gpio-mpsse + refactor the
driver
- use software nodes for configuring the reset-gpio driver, including
setting up the reference to the shared "reset" pin
- check and propagate the return value of gpiod_set_value() to
user-space in gpio-virtuser (this was previously not possible as
this function returned void)
- extend the gpio-regmap helper with more features (bypass cache for
aliased inputs, force writes for aliased data registers, add a new
configuration parameter)
- remove unneeded includes from gpio-aspeed and gpio-latch
- add support for Tegra410 to gpio-tegra186
- replace PCI-specific PM with generic device-level PM in gpio-bt8xx
- use dynamic GPIO range allocation in gpio-loongson-64bit
- improve handling of level-triggered interrupts in gpio-pca953x
- add suspend/resume support to gpio-fxl6408
- add support for more models to gpio-menz127
- optimize gpio-mvebu interrupt handling by avoiding unnecessary
calls to mvebu_gpio_irq_handler()
- make locking more consistent in gpio-grgpio
Device-tree bindings:
- document new NXP and Microchip models
Documentation:
- add a comprehensive compatibility and feature list for
gpio-pca953x, which is a great addition as it's probably the most
commonly used GPIO expander driver
- kernel-doc tweaks
Late fixes:
- use BYTE_CTRL_MODE for 2K2000/3000 models in gpio-loongson"
* tag 'gpio-updates-for-v6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (80 commits)
gpio: loongson: Switch 2K2000/3000 GPIO to BYTE_CTRL_MODE
gpio: regmap: fix kernel-doc notation
gpio: shared: fix a deadlock
gpio: shared-proxy: set suppress_bind_attrs
gpio: shared: ignore GPIO hogs when traversing the device tree
gpio: shared: ignore special __symbols__ node when traversing device tree
gpio: shared: handle the reset-gpios corner case
gpio: zynq: Use modern PM macros
gpio: xilinx: Use modern PM macros
gpio: xgene: Use modern PM macros
gpio: uniphier: Use modern PM macros
gpio: tqmx86: Use modern PM macros
gpio: pch: Use modern PM macros
gpio: omap: Use modern PM macros
gpio: msc313: Use modern PM macros
gpio: mlxbf2: Use modern PM macros
gpio: ml-ioh: Use modern PM macros
gpio: pl061: Use modern PM macros
gpio: htc-egpio: Use modern PM macros
gpio: brcmstb: Use modern PM macros
...
This release includes two changes for core functions, which affects all
use cases of this subsystem.
- Handle per-device interoperability quirks
It is well known that some devices have quirks affecting
interoperability. To identify such quirks at an early stages of
device detection, the step for reading the configuration ROM contents
has been changed. As a side effect, the entire detection process is
now performed at the basic transaction speed (S100), without no trial
to probe higher supported speeds.
With this change, the following devices should now work with fewer
issues:
- TASCAM FW-1884, FW-1804, and FW-1082
- MOTU Audio Express
- Safer removals of host card
There was a race condition between host card removal and handling of
bus reset events in the workqueue. This appears to be a long standing
issue (for a dozen years or so[1]), and recent changes to use more
workqueues escalate it. To solve it, a new callback has been added to
the 1394 OHCI PCI driver to unregister the interrupt sources and wait
for workqueue completions when removing a card instance.
[1] https://sourceforge.net/p/linux1394/mailman/linux1394-devel/thread/20250629024836.GA16759%40workstation.local/#msg59200628
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQE66IEYNDXNBPeGKSsLtaWM8LwEwUCaS4gGwAKCRCsLtaWM8Lw
E1EhAP48BItL1FUcn1oHGU019iHCE57vTOxPE89LXlinAe7GAAD/WUq77tQ84RUJ
gCuml3cWgRJuDqT6rksDQNNPOFbPbgI=
=B7Xh
-----END PGP SIGNATURE-----
Merge tag 'firewire-updates-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire updates from Takashi Sakamoto:
"This includes two changes for core functions, which affects all use
cases of this subsystem:
- Handle per-device interoperability quirks
Some devices have quirks affecting interoperability. To identify
such quirks at an early stages of device detection, the step for
reading the configuration ROM contents has been changed. As a side
effect, the entire detection process is now performed at the basic
transaction speed (S100), without a trial to probe higher
supported speeds.
With this change, the following devices should now work with fewer
issues:
- TASCAM FW-1884, FW-1804, and FW-1082
- MOTU Audio Express
- Safer removals of host card
There was a race condition between host card removal and handling
of bus reset events in the workqueue. This appears to be a long
standing issue, and recent changes to use more workqueues escalate
it.
To solve it, a new callback has been added to the 1394 OHCI PCI
driver to unregister the interrupt sources and wait for workqueue
completions when removing a card instance"
* tag 'firewire-updates-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: core: abort pending transactions at card removal
firewire: core: add WQ_UNBOUND to alloc_workqueue users
firewire: core: clear sources of hardware interrupt at card removal
firewire: core: code refactoring to find and pop transaction entry
firewire: core: code refactoring to remove transaction entry
firewire: core: use cleanup function to release cached configuration ROM
ALSA: firewire-tascam: reserve resources for transferred isochronous packets at S400
firewire: core: handle device quirk of TASCAM FW-1884/FW-1804/FW-1082
firewire: core: determine transaction speed after detecting quirks
firewire: core: code refactoring to compute transaction speed
firewire: core: handle device quirk of MOTU Audio Express
firewire: core: detect device quirk when reading configuration ROM
* New drivers
- Driver for Apple Silicon SMC
- Driver for TSC1641 I2C power monitor
- Driver for MPS MP9945
- Driver for MAX17616
- Driver for MP2925 and MP2929
* Added support for new devices to existing drivers
- dell-smm: Add Dell G5 5505 to fan control whitelist
- aspeed-g6-pwm-tach: Support for AST2700
- asus-ec-sensors: Support for ROG STRIX X470-I GAMING,
ROG STRIX X870-F GAMING WIFI, ROG STRIX X870E-H GAMING WIFI7,
and Pro WS TRX50-SAGE WIFI
- k10temp: Support for AMD Steam Deck APU ID
- pmbus/isl68137: Support for raa229141
- aht10: Support for dht20
- adt7410: Support for ADT7422
- peci: Support for Intel Emerald Rapids
- nct6775: Support for ASUS ROG STRIX X870E-H GAMING WIFI7
- pmbus/max34440: Support for ADPM12200
- ntc-thermistor: Support for Murata ncp18wm474
* Infrastructure updates
- Utilize subsystem locking in various drivers
- ltc4282, ltc2947: Use the new energy64 attribute
* Bug fixes
- Various drivers: Fixes to avoid TOCTOU, mostly in macro functions
evaluating parameters multiple times, as well as missing locks
- max6697: Fix regmap leak on probe failure
- sy7636a: Fix regulator_enable resource leak on error path
- asus-ec-sensors: Correct Pro WS TRX50-SAGE WIFI entry
* Other changes and improvements
- w83781d, lm78: Drop REALLY_SLOW_IO
- Fix broken datasheet links in various drivers
* Various other minor fixes and improvements
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEiHPvMQj9QTOCiqgVyx8mb86fmYEFAmkt7bIACgkQyx8mb86f
mYGV4w/9FGzFpNuC2nWEF9DvAgv2NmdEpx9Om/VUxMJ9gaWxUbKuQkO/Ac52SH3R
9zESbdiBYphDNXnCT2SSsS5+lT3WSBqoSKaiKZR706KjC3UDu6yKug6d4Ku9rXNX
OCfW6uhb+xrs47w0FG4ZJ38UVO0bV70ceLbo3glPm4YL9GXxRSWzbUxPJCbN65cU
lo2TFSAvf52jczjBjvgHnKGi0CMkil68G1Vx4OhvnAa+DW6BqDvJgpUPHPcb6HmB
n7k7mVME8MGL+i4OON9iPQd+wJ3BAALnLr5SSbz3Y8vxNNfTWSOYbEMgOFTi+zdi
CLtFxEqQmDbbP93Za5lSZP0x2CQtgxFd8y7X5BmheNwTs/06FxMmBc2/oFVjHDtv
gUQml/HREtNwwIc+OdSESRPSNvNM1YYO5FXczezE70IypWvpPUPLJHBXzh8dOhMl
WUddo6H5GzV2IKWyiuPCzMWCKIkzzCebklWA7VL0BcPao28JUVYtEiInf/6k7Xwt
OLrmKwT8OT7TkZdKXUXDqquGbsAwBmco66K7GWMuH60XTyn80ilTUZ+GrJiR3rNI
GvNexGBA+qv4xSV7ilSHjJh0vdXzdv0zHghqG67tti+nApI3+9oSRYmdCIaf+y0i
k5msMjtvWC1xCPxTyyjLIKIjKwR/8SmGw7C8MvEFEnPbLbepr4M=
=NviP
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon updates from Guenter Roeck:
"New drivers:
- Apple Silicon SMC
- TSC1641 I2C power monitor
- MPS MP9945
- MAX17616
- MP2925 and MP2929
Added support for new devices to existing drivers:
- dell-smm: Add Dell G5 5505 to fan control whitelist
- aspeed-g6-pwm-tach: Support for AST2700
- asus-ec-sensors: Support for ROG STRIX X470-I GAMING, ROG STRIX
X870-F GAMING WIFI, ROG STRIX X870E-H GAMING WIFI7, and Pro WS
TRX50-SAGE WIFI
- k10temp: Support for AMD Steam Deck APU ID
- pmbus/isl68137: Support for raa229141
- aht10: Support for dht20
- adt7410: Support for ADT7422
- peci: Support for Intel Emerald Rapids
- nct6775: Support for ASUS ROG STRIX X870E-H GAMING WIFI7
- pmbus/max34440: Support for ADPM12200
- ntc-thermistor: Support for Murata ncp18wm474
Infrastructure updates:
- Utilize subsystem locking in various drivers
- ltc4282, ltc2947: Use the new energy64 attribute
Bug fixes:
- Various drivers: Fixes to avoid TOCTOU, mostly in macro functions
evaluating parameters multiple times, as well as missing locks
- max6697: Fix regmap leak on probe failure
- sy7636a: Fix regulator_enable resource leak on error path
- asus-ec-sensors: Correct Pro WS TRX50-SAGE WIFI entry
Other changes and improvements:
- w83781d, lm78: Drop REALLY_SLOW_IO
- Fix broken datasheet links in various drivers
And various other minor fixes and improvements"
* tag 'hwmon-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (110 commits)
hwmon: (dell-smm) Add Dell G5 5505 to fan control whitelist
hwmon: (max16065) Use local variable to avoid TOCTOU
hwmon: (w83l786ng) Convert macros to functions to avoid TOCTOU
hwmon: (max6697) fix regmap leak on probe failure
hwmon/w83781d: Drop REALLY_SLOW_IO setting
hwmon/lm78: Drop REALLY_SLOW_IO setting
hwmon: sy7636a: Fix regulator_enable resource leak on error path
hwmon: (adm1026) Convert macros to functions to avoid TOCTOU
hwmon: (adm1029) Add locking to avoid TOCTOU
hwmon: (lm87) Convert macros to functions to avoid TOCTOU
hwmon: (asus-ec-sensors) correct Pro WS TRX50-SAGE WIFI entry
hwmon: (vt8231) Convert macros to functions to avoid TOCTOU
hwmon: (emc2103) Add locking to avoid TOCTOU
hwmon: (aspeed-g6-pwm-tach): Add AST2700 compatible string
dt-bindings: hwmon: Add AST2700 compatible
hwmon: (asus-ec-sensors) add ROG STRIX X470-I GAMING
hwmon: (vt1211) Convert macros to functions to avoid TOCTOU
hwmon: (k10temp) Add AMD Steam Deck APU ID
hwmon: Add Apple Silicon SMC hwmon driver
Documentation/hwmon: Fix broken datasheet links for zl6100
...
Here are the GNSS updates for 6.19-rc1, including:
- add support for claiming and deasserting the safeboot pin found on
recent u-blox receivers
- fix timepulse pin description in the devicetree binding
Included are also some related binding updates.
All have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCaS19CQAKCRALxc3C7H1l
CAbaAP9zkCo0ktuYLP6rBQv3Kp2GqQt/K2w+P+A+AUNU4T3c4QD/ZdQEMPqBUX5L
rGktYc/rFqWetfv8iuOEl1xBaOVayAY=
=391d
-----END PGP SIGNATURE-----
Merge tag 'gnss-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss
Pull GNSS updates from Johan Hovold:
- add support for claiming and deasserting the safeboot pin found on
recent u-blox receivers
- fix timepulse pin description in the devicetree binding
... and some related binding updates
* tag 'gnss-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss:
dt-bindings: gnss: fix timepulse description
dt-bindings: gnss: u-blox: use lowercase company name
dt-bindings: gnss: u-blox: use open-drain reset and safeboot in example
gnss: ubx: add support for the safeboot gpio
dt-bindings: gnss: u-blox: add safeboot gpio
This release is almost entirely new drivers, with a couple of small
changes in generic code. The biggest individual update is a rename of
the existing Microchip driver and the addition of a new driver for the
silicon SPI controller in their PolarFire SoCs. The overlap between the
soft IP supported by the current driver and this new one is regrettably
all in the IP and not in the register interface offered to software.
- Add a time offset parameter for offloads, allowing them to be defined
in relation to each other. This is useful for IIO type applcations
where you trigger an operation then read the result after a delay.
- Add a tracepoint for flash exec_ops, bringing the flash support more
in line with the debuggability of vanilla SPI.
- Support for Airoha EN7523, Arduino MCUs, Aspeed AST2700, Microchip
PolarFire SPI controllers, NXP i.MX51 ECSPI target mode, Qualcomm
IPQ5414 and IPQ5332, Renesas RZ/T2H, RZ/V2N and RZ/2NH and SpacemiT K1
QuadSPI.
There's also a small set of ASoC cleanups that I mistakenly applied to
the SPI tree and then put more stuff on top of before it was brought to
my attention, sorry about that.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmkt8qUACgkQJNaLcl1U
h9COSAf/buDi3hXYykhEbSlwl839u1XhCU9d8eJF8GhlWR87JeJCb8ou7RdMOQhE
HFehdoD2d5EcPc169cDp2uis8LovGZIPWuzh3D83eZpOOQTLMaQYBrDVNquBoKOR
WVFPPy9X/kb/IR63vM0b5Xv9K6l3ud4yauIsa0ingl9pZi5m2fB3ZEOx9siYYwAn
4fxv43jESbwdTfx33Yc4CkzctZEKuqI2JgLNe/mJZQsdYhS/nLvmDwiZ69k6b4ac
QSHQkP6i+fQzogcbip2z8dA3IUEhDjNQdBbtzmIot8Qbg7zXJkXpAlx2Wstw7Lt8
vLTUY/EHqKh39zok5GECq6E2R6W41w==
=Uw2/
-----END PGP SIGNATURE-----
Merge tag 'spi-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"This release is almost entirely new drivers, with a couple of small
changes in generic code.
The biggest individual update is a rename of the existing Microchip
driver and the addition of a new driver for the silicon SPI controller
in their PolarFire SoCs. The overlap between the soft IP supported by
the current driver and this new one is regrettably all in the IP and
not in the register interface offered to software.
- Add a time offset parameter for offloads, allowing them to be
defined in relation to each other. This is useful for IIO type
applcations where you trigger an operation then read the result
after a delay.
- Add a tracepoint for flash exec_ops, bringing the flash support
more in line with the debuggability of vanilla SPI.
- Support for Airoha EN7523, Arduino MCUs, Aspeed AST2700, Microchip
PolarFire SPI controllers, NXP i.MX51 ECSPI target mode, Qualcomm
IPQ5414 and IPQ5332, Renesas RZ/T2H, RZ/V2N and RZ/2NH and SpacemiT
K1 QuadSPI.
There's also a small set of ASoC cleanups that I mistakenly applied to
the SPI tree and then put more stuff on top of before it was brought
to my attention, sorry about that"
* tag 'spi-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (80 commits)
spi: microchip-core: Refactor FIFO read and write handlers
spi: ch341: fix out-of-bounds memory access in ch341_transfer_one
spi: microchip-core: Remove unneeded PM related macro
spi: microchip-core: Use SPI_MODE_X_MASK
spi: microchip-core: Utilise temporary variable for struct device
spi: microchip-core: Replace dead code (-ENOMEM error message)
spi: microchip-core: use min() instead of min_t()
spi: dt-bindings: airoha: add compatible for EN7523
spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was short to GND
spi: dt-bindings: renesas,rzv2h-rspi: Document RZ/V2N SoC support
spi: dt-bindings: renesas,rzv2h-rspi: Document RZ/V2N SoC support
spi: microchip: Enable compile-testing for FPGA SPI controllers
spi: Fix potential uninitialized variable in probe()
spi: rzv2h-rspi: add support for RZ/T2H and RZ/N2H
spi: dt-bindings: renesas,rzv2h-rspi: document RZ/T2H and RZ/N2H
spi: rzv2h-rspi: add support for loopback mode
spi: rzv2h-rspi: add support for variable transfer clock
spi: rzv2h-rspi: add support for using PCLK for transfer clock
spi: rzv2h-rspi: make transfer clock rate finding chip-specific
spi: rzv2h-rspi: avoid recomputing transfer frequency
...
This is a relatively busy release for the regulator API, as well as a
good collection of new drivers we've got a little bit of core work and a
bunch of cleanup throughout the subsystem:
- Support for propagating undervoltage events to child regulators.
- Undo enables done on supplies when setting enabling regulators via
constraints fails.
- Pull in some gpiolib changes adding support for shared GPIOs to
the gpiolib core, using them to replace the open coded variant of this
that we've had in the regulator API for a long time.
- Support for Fitipower FP9931 and JD9330, Mediatek MT6316, MT6363 and
MT6373, NXP PF1550 and Qualcomm PMH01XX and PMCX0102
The PF1550 support was originally going to go via the MFD tree but
Krzysztof's cleanup work overlapped with it so I pulled in Lee's signed
tag with support for the device.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmkt72UACgkQJNaLcl1U
h9Dm2wf+JhjBLxviOozOhSv17wKnCYpApL12vPIHhv3lGu4J9wPiqqe3eB6PrTPo
xkuIb8u68wOveh7uLgr/kprH/YUxofrkCEwZjy57geSanuqIEzVoqU//4NKca9ND
UeoDiTYLx5JQVzlo12tSFhLCvDsFgdnemWFfubRPQGTJA/RElMxrNySf3yUQbYBE
ODpTGbXqt4LnYQTJRvVM8/0KzREpxD0X8fSISKpA3KYBFntMexZcgrs5pqijwfMS
Euxff2UpFzjodmYEusWfKOFeZXmd/cClF26Tol7oaeaurr1pNu1i0nBUprbd/rzL
YTV8QeiftLqER/h2iDX4f8iTmvVhzA==
=9IkF
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This is a relatively busy release for the regulator API, as well as a
good collection of new drivers we've got a little bit of core work and
a bunch of cleanup throughout the subsystem:
- Support for propagating undervoltage events to child regulators
- Undo enables done on supplies when setting enabling regulators via
constraints fails
- Pull in some gpiolib changes adding support for shared GPIOs to the
gpiolib core, using them to replace the open coded variant of this
that we've had in the regulator API for a long time
- Support for Fitipower FP9931 and JD9330, Mediatek MT6316, MT6363
and MT6373, NXP PF1550 and Qualcomm PMH01XX and PMCX0102
The PF1550 support was originally going to go via the MFD tree but
Krzysztof's cleanup work overlapped with it so I pulled in Lee's
signed tag with support for the device"
* tag 'regulator-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (50 commits)
regulator: fp9931: Fix spelling mistake "failid" -> "failed"
regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex
regulator: pf9453: Constify pointers to 'regulator_desc' wrap struct
regulator: pca9450: Constify pointers to 'regulator_desc' wrap struct
regulator: mt6358: Constify pointers to 'regulator_desc' wrap struct
regulator: bd96801: Constify pointers to 'regulator_desc' wrap struct
regulator: bd718x7: Constify pointers to 'regulator_desc' wrap struct
regulator: bd71828: Constify pointers to 'regulator_desc' wrap struct
regulator: bd71815: Constify pointers to 'regulator_desc' wrap struct
regulator: Use container_of_const() when all types are const
regulator: pca9450: Fix error code in probe()
regulator: qcomm-labibb: replace use of system_wq with system_dfl_wq
regulator: Add FP9931/JD9930 driver
dt-bindings: regulator: Add Fitipower FP9931/JD9930
dt-bindings: vendor-prefixes: Add Fitipower
regulator: make the subsystem aware of shared GPIOs
regulator: renesas-usb-vbus-regulator: Remove unused headers
regulator: pca9450: Add support for setting debounce settings
regulator: dt-bindings: pca9540: add debounce timer configuration
regulator: core: disable supply if enabling main regulator fails
...
Another small update for regmap, we have one new feature plus a little
bit of cleanup:
- Support for sparseness information in the flat cache, allowing users
that really need the performance properties it provides to benefit
from the interface and startup time improvements that sparsness provides
without needing to go all the way to a more fancy data structure.
- Cleanup work from Andy Shevchenko, refactoring the cache interface
in preparation for some future stuff he's working on.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmkt6/0ACgkQJNaLcl1U
h9A33gf/QC/O/zxVtpq31+CtC1k3ola0rWrLxOnQKywoUcBjJqX+FiFqL+MDS6Mw
RfXzX7SmzJup71/sg7GNQjRSL3jH3UmsAy4acbNhoCXwi0VaFibHfTqVKNQGK5um
uzsDP8Ue4zUyqym3jMKxs36iVYtt9/QcUjrubumisnB51csQKQ0tn7+2khUbN7D5
PEjUfR7WiGAGDf2AmCLueCYaV16uuzoxnlV9U4Mp5LYvzi5KKxZZAid9ppUCUcAt
uab8Y5Qo8uxBKJEue1vp4shfbxj69GoOdzOP8bYWNP2z6xcHXgK2ma/5y3eqK7L0
uA1SHqKW3QXY1VckI83QWrifR6r8mQ==
=TTeH
-----END PGP SIGNATURE-----
Merge tag 'regmap-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap updates from Mark Brown:
"Another small update for regmap, we have one new feature plus a little
bit of cleanup:
- Support for sparseness information in the flat cache, allowing
users that really need the performance properties it provides to
benefit from the interface and startup time improvements that
sparsness provides without needing to go all the way to a more
fancy data structure
- Cleanup work from Andy Shevchenko, refactoring the cache interface
in preparation for some future stuff he's working on"
* tag 'regmap-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: sdw-mbq: Reorder regmap_mbq_context struct for better packing
regmap: i3c: Use ARRAY_SIZE()
regcache: maple: Split ->populate() from ->init()
regcache: flat: Split ->populate() from ->init()
regcache: flat: Remove unneeded check and error message for -ENOMEM
regcache: rbtree: Split ->populate() from ->init()
regcache: Add ->populate() callback to separate from ->init()
regmap: warn users about uninitialized flat cache
regmap: add flat cache with sparse validity
- We must ignore error -ENOENT from parsers on subpartitions which is a
legitimate return value.
- PM support is added to the intel-dg driver.
Raw NAND changes:
- The major change in this MR will be the support for the Allwinner H616
NAND controller, which lead to numerous changes and cleanups in the
driver.
- Another notable change on this driver is the use of
field_get()/field_prep(), but since the global support for this
helpers is going to be merged in the same release as we start using
these helpers, it implies undefining them in the first place to avoid
warnings. Depending on the merging order (Yuri's bitmap branch or
mtd/next), a temporary warning may arise.
- Marvell drivers layout handling changes have also landed, they fix
previous definitions and abuses that have been made previously, which
implied to relax the ECC parameters validation in the core a bit.
- The Cadence NAND controller driver gets NV-DDR interface support.
SPI NAND changes:
- Support for FudanMicro FM25S01BI3 and ESMT F50L1G41LC is added.
SPI NOR changes:
- Fix SMPT parsing for S25FS-S flash family. They report variable dummy
cycles for reads. This results in the default of 0 being used. This
works for other Infineon chips, but not for the S25FS-S family. They
need 8 dummy cycles. Add fixup hooks to specify that. Also add fixup
hooks to fix incorrect map ID data in SFDP.
- Add support for a bunch of Winbond flashes. Their block protection
information is not discoverable, so they need to have an entry in the
flash tables to describe that.
- Some cleanups for Micron flash support.
- Add support for Micron mt35xu01gbba.
- Some SPI controllers like the Intel one on the PCI bus do not support
the read CR opcode (0x35). Do not use the opcode if the controller
does not support it.
Aside from these main changes, there is the usual load of API updates,
kdoc fixes, potential memory leaks fixes, etc.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmkq8aMACgkQJWrqGEe9
VoRxNQgAti0loJ+uUcjWwvpGkpC6/g1W1j+qMWdBUiiG8F+la23A8vT/HEAna0sD
H9fl8ZeDZYG4YQR3OWBbOs6b7DHdor6QEd08szM35mgJkDT40qyGka1nnwd1KPjS
4+xRPY0Lyx2V612mB8f6yXhvH5GOpskg5JLS65lzjSbyTb8BMCk6uu87eAVViDuw
Q8dOpN/LgbXp5B1H/23CM6Lvgj+Ok2ETLND7l2jW9yE8SSA04J+7Lth4uNSW4k/J
1ZKcaooPBaj7paPxz/C9f3VyxoLN3+YHMjdvt5rI17bwKfsR8PbdVpvdgIqpv1yn
UG84IfsOHP8JDzUHSyKE+9DNgz4Bew==
=8uoN
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd updates from Miquel Raynal:
"Core MTD changes:
- We must ignore error -ENOENT from parsers on subpartitions which is
a legitimate return value
- PM support is added to the intel-dg driver
Raw NAND changes:
- The major change in this is the support for the Allwinner H616 NAND
controller, which lead to numerous changes and cleanups in the
driver.
- Another notable change in this driver is the use of field_get() and
field_prep(), but since the global support for this helpers is
going to be merged in the same release as we start using these
helpers, we undefine them in the first place to avoid warnings.
- Marvell drivers layout handling changes have also landed, they fix
previous definitions and abuses that have been made previously,
which implied to relax the ECC parameters validation in the core a
bit.
- The Cadence NAND controller driver gets NV-DDR interface support.
SPI NAND changes:
- Support for FudanMicro FM25S01BI3 and ESMT F50L1G41LC is added.
SPI NOR changes:
- Fix SMPT parsing for S25FS-S flash family. They report variable
dummy cycles for reads. This results in the default of 0 being
used. This works for other Infineon chips, but not for the S25FS-S
family. They need 8 dummy cycles. Add fixup hooks to specify that.
Also add fixup hooks to fix incorrect map ID data in SFDP.
- Add support for a bunch of Winbond flashes. Their block protection
information is not discoverable, so they need to have an entry in
the flash tables to describe that.
- Some cleanups for Micron flash support.
- Add support for Micron mt35xu01gbba.
- Some SPI controllers like the Intel one on the PCI bus do not
support the read CR opcode (0x35). Do not use the opcode if the
controller does not support it.
Aside from these main changes, there is the usual load of API updates,
kdoc fixes, potential memory leaks fixes, etc"
* tag 'mtd/for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (51 commits)
mtd: sm_ftl: Fix typo in comment in sm_read_lba
mtd: sm_ftl: Replace deprecated strncpy with sysfs_emit in sm_attr_show
mtd: lpddr_cmds: fix signed shifts in lpddr_cmds
mtd: docg3: fix kernel-doc warnings
mtd: spinand: add support for FudanMicro FM25S01BI3
mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors
mtd: nand: realtek-ecc: Fix Kconfig dependencies
mtd: rawnand: sunxi: #undef field_{get,prep}() before local definition
mailmap: update Pratyush Yadav's email address
mtd: spi-nor: core: Check read CR support
mtd: spi-nor: micron-st: add TODO for fixing mt35xu02gcba
mtd: spi-nor: micron-st: add mt35xu01gbba support
mtd: spi-nor: micron-st: use SFDP of mt35xu512aba
mtd: spi-nor: micron-st: move set_octal_dtr to late_init()
mtd: spi-nor: micron-st: rename the die_late_init functions
mtd: spinand: esmt: add support for F50L1G41LC
mtd: rawnand: lpc32xx_slc: Convert to use devm_gpiod_get_optional()
mtd: mtdpart: ignore error -ENOENT from parsers on subpartitions
mtd: maps: pcmciamtd: fix potential memory leak in pcmciamtd_detach()
mtd: spi-nor: spansion: SMPT fixups for S25FS-S
...
Additional to the usual mix of core cleanups, driver changes, minor
fixes and device tree updates the highlight this cycle is Rust support
for the core and a first Rust driver both provided by Michal Wilczynski.
Michal wrote about these changes on
https://mwilczynski.dev/posts/bringing-rust-to-the-pwm-subsystem/ which
is a nice read.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmktTeIACgkQj4D7WH0S
/k5iuQf+KXBvcSYimI53UNQsT2e9uZc794w6tpQrauHuDp/szFyiGo6XaM+Hir3I
PS2F/2knI6puRlIyPFIxedlgSzNfpU5mXfNM86CmeuNefWVvOGBTU4lLg3ifEgGD
CU7mbV0HMVLX749CDTbrYxIPmSNnIx8bj5V4YIm78QtR3j2L6iTZIaXeF2Ip2FAI
AhNjkar3jk6apg5rbtSLC8At9OG5/JVgEdTuXCaEjCtnEkPz9Z4VPMOwzxzCK24q
EHPTBpAM+psBBr3KOTSMjAuVqfrx07L47e7597XitzcdGg+zVaOnFZpuWER1/t7+
1EAf8wlcYhi3GnUyXbaBzYq1FfhfEA==
=x9B8
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux
Pull pwm updates from Uwe Kleine-König:
"In addition to the usual mix of core cleanups, driver changes, minor
fixes and device tree updates the highlight this cycle is Rust support
for the core and a first Rust driver both provided by Michal
Wilczynski.
Michal wrote about these changes on
https://mwilczynski.dev/posts/bringing-rust-to-the-pwm-subsystem/
which is a nice read"
* tag 'pwm/for-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: (22 commits)
pwm: rzg2l-gpt: Allow checking period_tick cache value only if sibling channel is enabled
pwm: bcm2835: Make sure the channel is enabled after pwm_request()
pwm: mediatek: Make use of struct_size macro
pwm: mediatek: Remove unneeded semicolon
pwm: airoha: Add support for EN7581 SoC
pwm: mediatek: Convert to waveform API
pwm: max7360: Clean MAX7360 code
pwm: Drop unused function pwm_apply_args()
pwm: Use %u to printf unsigned int pwm_chip::npwm and pwm_chip::id
pwm: Simplify printf to emit chip->npwm in $debugfs/pwm
pwm: th1520: Use module_pwm_platform_driver! macro
pwm: th1520: Fix clippy warning for redundant struct field init
pwm: Fix Rust formatting
dt-bindings: pwm: thead: Add T-HEAD TH1520 PWM controller
pwm: Add Rust driver for T-HEAD TH1520 SoC
rust: pwm: Fix broken intra-doc link
rust: pwm: Drop wrapping of PWM polarity and state
rust: pwm: Add module_pwm_platform_driver! macro
rust: pwm: Add complete abstraction layer
rust: pwm: Add Kconfig and basic data structures
...
* Improvements
- Support legacy probe behavior in cros_ec_lightbar and
cros_ec_sensorhub.
* Fixes
- Don't fall back to legacy probe behavior if it isn't a legacy device
in cros_usbpd_notify.
- Fix an UAF after unbinding driver in cros_ec_ishtp.
-----BEGIN PGP SIGNATURE-----
iIkEABYKADEWIQS0yQeDP3cjLyifNRUrxTEGBto89AUCaS0NnhMcdHp1bmdiaUBr
ZXJuZWwub3JnAAoJECvFMQYG2jz069QA/09FZ8htBY63DVoo0IBUiRbsZkeDa7is
F6oGB1iyQh55AQDlyDBKhjs2zdFLoilz23q5o4ufQJcK4M7ieteFzva7Cw==
=LyL1
-----END PGP SIGNATURE-----
Merge tag 'chrome-platform-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform updates from Tzung-Bi Shih:
"Improvements:
- Support legacy probe behavior in cros_ec_lightbar and
cros_ec_sensorhub
Fixes:
- Don't fall back to legacy probe behavior if it isn't a legacy
device in cros_usbpd_notify
- Fix an UAF after unbinding driver in cros_ec_ishtp"
* tag 'chrome-platform-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: sensorhub: Support devices without FIFO_INT_ENABLE
platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driver
platform/chrome: cros_ec_lightbar: Check if ec supports suspend commands
platform/chrome: cros_usbpd_notify: defer probe when parent EC driver isn't ready
- Use max() instead of max_t() to ease static analysis (David Laight)
- Add Manivannan Sadhasivam as PCI/pwrctrl maintainer (Bartosz Golaszewski)
* pci/misc:
MAINTAINERS: Add Manivannan Sadhasivam as PCI/pwrctrl maintainer
PCI: Use max() instead of max_t() to ease static analysis
- Add a struct pci_ops.assert_perst() function pointer to assert/deassert
PCIe PERST# and implement it for the qcom driver (Krishna Chaitanya
Chundru)
- Add DT binding and pwrctrl driver for the Toshiba TC9563 PCIe switch,
which must be held in reset after poweron so the pwrctrl driver can
configure the switch via I2C before bringing up the links (Krishna
Chaitanya Chundru)
* pci/pwrctrl-tc9563:
PCI: pwrctrl: Add power control driver for TC9563
PCI: qcom: Implement .assert_perst()
PCI: dwc: Implement .assert_perst() for dwc glue drivers
PCI: Add .assert_perst() to control PCIe PERST#
dt-bindings: PCI: Add binding for Toshiba TC9563 PCIe switch
- Fix a race between link training and endpoint register initialization
(Christian Bruel)
- Align endpoint allocations to match the ATU requirements (Christian
Bruel)
- Add #includes to avoid depending on 'proxy' headers (Andy Shevchenko)
* pci/controller/stm32:
PCI: stm32: Don't use 'proxy' headers
PCI: stm32: Fix EP page_size alignment
PCI: stm32: Fix LTSSM EP race with start link
- Add module support for platform controller driver (Manikandan K Pillai)
- Split headers into 'legacy' (LGA) and 'high perf' (HPA) (Manikandan K
Pillai)
- Add DT binding and driver for CIX Sky1 (Hans Zhang)
* pci/controller/sky1:
MAINTAINERS: Add CIX Sky1 PCIe controller driver maintainer
PCI: sky1: Add PCIe host support for CIX Sky1
dt-bindings: PCI: Add CIX Sky1 PCIe Root Complex bindings
PCI: cadence: Add support for High Perf Architecture (HPA) controller
PCI: cadence: Move PCIe RP common functions to a separate file
PCI: cadence: Split PCIe controller header file
PCI: cadence: Add module support for platform controller driver
- Drop ARM dependency so we can build test on other arches (Geert
Uytterhoeven)
* pci/controller/rcar-gen2:
PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2
- Look up OPP using both frequency and data rate (not just frequency) so
RPMh votes can account for both (Krishna Chaitanya Chundru)
* pci/controller/qcom:
PCI: qcom: Use frequency and level based OPP lookup
- Update DT binding to name DBI region "dbi", not "elbi", and update driver
to support both (Manivannan Sadhasivam)
* pci/controller/meson:
PCI: meson: Fix parsing the DBI register region
dt-bindings: PCI: amlogic: Fix the register name of the DBI region
- Convert DT binding to YAML schema (Christian Marangi)
- Add Airoha AN7583 DT compatible and driver support (Christian Marangi)
* pci/controller/mediatek:
PCI: mediatek: Add support for Airoha AN7583 SoC
PCI: mediatek: Use generic MACRO for TPVPERL delay
PCI: mediatek: Convert bool to single quirks entry and bitmap
dt-bindings: PCI: mediatek: Add support for Airoha AN7583
dt-bindings: PCI: mediatek: Convert to YAML schema
- Fail the probe instead of silently succeeding if ks_pcie_of_data
didn't specify Root Complex or Endpoint mode (Siddharth Vadapalli)
- Make keystone buildable as a loadable module, except on ARM32 where
hook_fault_code() is __init (Siddharth Vadapalli)
* pci/controller/keystone:
PCI: keystone: Add support to build as a loadable module
PCI: dwc: Export dw_pcie_allocate_domains() and dw_pcie_ep_raise_msix_irq()
PCI: Export pci_get_host_bridge_device() for use by pci-keystone
PCI: keystone: Exit ks_pcie_probe() for invalid mode
- Use devm_clk_get_optional_enabled() instead of open-coding
devm_clk_get_optional() and clk_prepare_enable() (Anand Moon)
* pci/controller/j721e:
PCI: j721e: Use 'pcie->reset_gpio' directly and drop the local variable
PCI: j721e: Use devm_clk_get_optional_enabled() to get and enable the clock
- Guard ARM32-specific hook_fault_code() with ifdefs so we can build test
on other arches (Bjorn Helgaas)
* pci/controller/ixp4xx:
PCI: ixp4xx: Guard ARM32-specific hook_fault_code()
- Update PORT_LOGIC_LTSSM_STATE_MASK to be a 6-bit mask as per spec, not a
5-bit mask (Shawn Lin)
- Clear L1 PM Substate Capability 'Supported' bits unless glue driver says
it's supported, which prevents users from enabling non-working L1SS.
Currently only qcom and tegra194 support L1SS (Bjorn Helgaas)
- Remove now-superfluous L1SS disable code from tegra194 (Bjorn Helgaas)
- Configure L1SS support in dw-rockchip when DT says 'supports-clkreq'
(Shawn Lin)
* pci/controller/dwc:
PCI: dw-rockchip: Configure L1SS support
PCI: tegra194: Remove unnecessary L1SS disable code
PCI: dwc: Advertise L1 PM Substates only if driver requests it
PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition
- Disable advertising ASPM L0s support correctly (Jim Quinlan)
- Add a panic/die handler to print diagnostic info in case PCIe caused an
unrecoverable abort (Jim Quinlan)
* pci/controller/brcmstb:
PCI: brcmstb: Add panic/die handler to driver
PCI: brcmstb: Add a way to indicate if PCIe bridge is active
PCI: brcmstb: Fix disabling L0s capability
- Convert the endpoint doorbell test to use a threaded IRQ to fix a
'sleeping while atomic' issue (Bhanu Seshu Kumar Valluri)
- Add endpoint VNTB MSI doorbell support to reduce latency between host and
endpoint (Frank Li)
* pci/endpoint:
PCI: endpoint: pci-epf-vntb: Add MSI doorbell support
PCI: endpoint: Add pci_epf_assign_bar_space() API
PCI: endpoint: Add pci_epf_get_required_bar_size() helper
PCI: endpoint: Rename 'epf_bar::aligned_size' to 'epf_bar:mem_size'
PCI: endpoint: pci-epf-test: Fix sleeping function being called from atomic context
- Prevent resource tree corruption when BAR resize fails (Ilpo Järvinen)
- Restore BARs to the original size if a BAR resize fails (Ilpo Järvinen)
- Remove BAR release from BAR resize attempts by the xe, i915, and amdgpu
drivers so the PCI core can restore BARs if the resize fails (Ilpo
Järvinen)
- Move Resizable BAR code to rebar.c (Ilpo Järvinen)
- Add pci_rebar_size_supported() and use it in i915 and xe (Ilpo Järvinen)
- Add pci_rebar_get_max_size() and use it in xe and amdgpu (Ilpo Järvinen)
* pci/resource:
PCI: Validate pci_rebar_size_supported() input
PCI: Convert BAR sizes bitmasks to u64
drm/amdgpu: Use pci_rebar_get_max_size()
drm/xe/vram: Use pci_rebar_get_max_size()
PCI: Add pci_rebar_get_max_size()
drm/xe/vram: Use PCI rebar helpers in resize_vram_bar()
drm/i915/gt: Use pci_rebar_size_supported()
PCI: Add pci_rebar_size_supported() helper
PCI: Improve Resizable BAR functions kernel doc
PCI: Move pci_rebar_size_to_bytes() and export it
PCI: Move pci_rebar_bytes_to_size() and clean it up
PCI: Move Resizable BAR code to rebar.c
PCI: Prevent restoring assigned resources
drm/amdgpu: Remove driver side BAR release before resize
drm/i915: Remove driver side BAR release before resize
drm/xe: Remove driver side BAR release before resize
PCI: Add kerneldoc for pci_resize_resource()
PCI: Fix restoring BARs on BAR resize rollback path
PCI: Free saved list without holding pci_bus_sem
PCI: Try BAR resize even when no window was released
PCI: Change pci_dev variable from 'bridge' to 'dev'
PCI/IOV: Adjust ->barsz[] when changing BAR size
PCI: Prevent resource tree corruption when BAR resize fails
- Enable PTM only if device advertises support for a relevant role, to
prevent invalid PTM Requests that cause ACS violations that are reported
as AER Uncorrectable Non-Fatal errors (Mika Westerberg)
* pci/ptm:
PCI/PTM: Enable only if device advertises relevant role
- For drivers using PCI legacy suspend, save config state at suspend so
that state (not any earlier state from enumeration, probe, or error
recovery) will be restored when resuming (Lukas Wunner)
- For devices with no driver or a driver that lacks PM, save config state
at hibernate so that state (not any earlier state from enumeration,
probe, or error recovery) will be restored when resuming (Lukas Wunner)
- Save device config space on device addition, before driver binding, so
error recovery works more reliably (Lukas Wunner)
- Drop pci_save_state() from several drivers that no longer need it since
the PCI core always does it and pci_restore_state() no longer invalidates
the saved state (Lukas Wunner)
- Document use of pci_save_state() by drivers to capture the state they
want restored during error recovery (Lukas Wunner)
* pci/err:
Documentation: PCI: Amend error recovery doc with pci_save_state() rules
treewide: Drop pci_save_state() after pci_restore_state()
PCI/ERR: Ensure error recoverability at all times
PCI/PM: Stop needlessly clearing state_saved on enumeration and thaw
PCI/PM: Reinstate clearing state_saved in legacy and !PM codepaths
- Enable host bridge emulation for PCI_DOMAINS_GENERIC platforms (Dan
Williams)
- Switch vmd from custom domain number allocator to the common allocator
(Dan Williams)
* pci/enumeration:
PCI: vmd: Switch to pci_bus_find_emul_domain_nr()
PCI: Enable host bridge emulation for PCI_DOMAINS_GENERIC platforms
Extracting empty examples results in just the empty template being
generated and then validated. That's pointless and not free, so filter
out the schemas without any examples from the targets.
There's currently a little less than 10% of the binding schema files
without examples. Removing them improves the build time by ~6%.
Link: https://patch.msgid.link/20251201175030.3785060-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Manivannan is doing a lot of work on the PCI power control. Add him as
maintainer.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251120082747.10541-1-brgl@bgdev.pl
Add driver for the CIX Sky1 SoC PCIe Gen4 16 GT/s controller based on the
Cadence High Performance Architecture (HPA) PCIe core.
The controller supports MSI/MSI-X via GICv3, Single Virtual Channel, and
Single Function.
Signed-off-by: Hans Zhang <hans.zhang@cixtech.com>
[mani: moved the PCI ID definitions and squashed Kconfig change]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: sort Kconfig menu entry, squash
https://lore.kernel.org/r/aSBqp0cglr-Sc8na@stanley.mountain]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251108140305.1120117-8-hans.zhang@cixtech.com
Document the bindings for CIX Sky1 PCIe Controller configured in Root
Complex mode with five Root Ports.
The controller supports 4 INTx, MSI and MSI-X interrupts with the help of
the ARM GICv3 interrupt controller.
Signed-off-by: Hans Zhang <hans.zhang@cixtech.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251108140305.1120117-6-hans.zhang@cixtech.com
Add register and bitfield definitions:
- GEN3_RELATED_OFF_EQ_PHASE_2_3 field of GEN3_RELATED_OFF
- Coherency control registers
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20251121164920.2008569-3-vincent.guittot@linaro.org
- Support for Logitech G Pro X Superlight 2 receiver (Nathan Rossi)
- Fix for retry logic in hidpp_send_message_sync() (Mavroudis Chatzilazaridis)
- Support for new Lighspeed receiver version (Mavroudis Chatzilazaridis)
- Support for Logitech G13 (Leo L. Schwab)
- Backlight support improvement for Logitech G510 (Hans de Goede)
Since commit 88bbe85dcd ("irqchip: bcm2836: Move SMP startup code to
arch/arm (v2)") the bcm2836-l1-intc block on bcm2711 is only used as a
base address for the smp_boot_secondary hook on 32 bit kernels. It is
not used as an interrupt controller.
Drop the binding requirement for interrupt-controller and interrupt-cells
to satisfy validation on this platform.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20241220-dt-bcm2712-fixes-v5-3-cbbf13d2e97a@raspberrypi.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Commit 6cfcbe548a ("dt-bindings: display: Add BCM2712 HVS bindings")
added the compatible string for BCM2712, but missed out that
the number of interrupts and clocks changed too.
The driver commit 7687a12153 ("drm/vc4: hvs: Add support for BCM2712
HVS") also requires that both interrupts and clocks are named, so the
relevant -names properties are also added to "required" for BCM2712.
Update to validate clock, interrupts, and their names for the BCM2712
variant. (There should be no change in the binding requirements for
the other variants).
Fixes: 6cfcbe548a ("dt-bindings: display: Add BCM2712 HVS bindings")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patch.msgid.link/20241220-dt-bcm2712-fixes-v5-2-cbbf13d2e97a@raspberrypi.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Commit 62948c62ab ("dt-bindings: display: Add BCM2712 HDMI bindings")
added the compatible strings for BCM2712, but missed out that the
number of interrupts changed with the "wakeup" interrupt not present in
the BCM7212.
Update the schema to correct the interrupt requirements for BCM2712.
(Requirements for BCM2711 should be unchanged).
Fixes: 62948c62ab ("dt-bindings: display: Add BCM2712 HDMI bindings")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patch.msgid.link/20241220-dt-bcm2712-fixes-v5-1-cbbf13d2e97a@raspberrypi.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
virtio UAPI headers really have no business pulling in kernel.h
Replace it with const.h which seems to be what's needed
for __KERNEL_DIV_ROUND_UP.
Fixes: 7c1ae151e8 ("virtio_pci: Introduce device parts access commands")
Cc: Yishai Hadas <yishaih@nvidia.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Message-ID: <7a73b6c6af67e13b86633cd7bf11ad56b5d9809b.1763535341.git.mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The current interface where caller has to know in which 64 bit chunk
each bit is, is inelegant and fragile.
Let's simply use arrays of bits.
By using unroll macros text size grows only slightly.
Message-ID: <637e182e139980e5930d50b928ba5ac072d628a9.1764225384.git.mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* The major change in this MR will be the support for the Allwinner H616
NAND controller, which lead to numerous changes and cleanups in the
driver.
* Another notable change on this driver is the use of
field_get()/field_prep(), but since the global support for this
helpers is going to be merged in the same release as we start using
these helpers, it implies undefining them in the first place to avoid
warnings. Depending on the merging order (Yuri's bitmap branch or
mtd/next), a temporary warning may arise.
* Marvell drivers layout handling changes have also landed, they fix
previous definitions and abuses that have been made previously, which
implied to relax the ECC parameters validation in the core a bit.
* The Cadence NAND controller driver gets NV-DDR interface support.
SPI NAND changes:
* Support for FudanMicro FM25S01BI3 and ESMT F50L1G41LC is added.
Aside from these main changes, there is the usual load of fixes and API
updates.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmkq7xoACgkQJWrqGEe9
VoTJHwf/eWFw8FcoRi7R7x0AfU5/V41usaqWyAFaYJMcsdNSJZJbG8yw0dJ8fjNq
udvfDW7hnlbInKTwNeKqtlCPEDFoFPwro6cio5Mv0N1jtKpdL/gyJsOaqz2/ojCc
UJiQI+999VIx31B7v2waoZL4SDoSknvKRpOLOwnSipp10Gu9Ruqjw8QAPPWCJx+E
RUcdO78EhZK1+kWbZu/FiIpk6Dwwl5HJBHydH5fR8D25R5Z+4ZTOaQubWUrvCybI
05pbJ8cX6cMp043FF6YXyJdTslEe1iu16x/GXdKNMANgUFNE1qAH6LeKP6jPtI0L
94fg93LBqhnoYiPKt5W5jXf//DSFKw==
=o8ar
-----END PGP SIGNATURE-----
Merge tag 'nand/for-6.19' into mtd/next
Raw NAND changes:
* The major change in this MR will be the support for the Allwinner H616
NAND controller, which lead to numerous changes and cleanups in the
driver.
* Another notable change on this driver is the use of
field_get()/field_prep(), but since the global support for this
helpers is going to be merged in the same release as we start using
these helpers, it implies undefining them in the first place to avoid
warnings. Depending on the merging order (Yuri's bitmap branch or
mtd/next), a temporary warning may arise.
* Marvell drivers layout handling changes have also landed, they fix
previous definitions and abuses that have been made previously, which
implied to relax the ECC parameters validation in the core a bit.
* The Cadence NAND controller driver gets NV-DDR interface support.
SPI NAND changes:
* Support for FudanMicro FM25S01BI3 and ESMT F50L1G41LC is added.
Aside from these main changes, there is the usual load of fixes and API
updates.
Notable changes:
- Fix SMPT parsing for S25FS-S flash family. They report variable dummy
cycles for reads. This results in the default of 0 being used. This
works for other Infineon chips, but not for the S25FS-S family. They
need 8 dummy cycles. Add fixup hooks to specify that. Also add fixup
hooks to fix incorrect map ID data in SFDP.
- Add support for a bunch of Winbond flashes. Their block protection
information is not discoverable, so they need to have an entry in the
flash tables to describe that.
- Some cleanups for Micron flash support.
- Add support for Micron mt35xu01gbba.
- Some SPI controllers like the Intel one on the PCI bus do not support
the read CR opcode (0x35). Do not use the opcode if the controller
does not support it.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQTlUWNzXGEo3bFmyIR4drqP028CQUCaSjP+QAKCRAR4drqP028
CfGsAQC5Vj+FaeQHyY+yywqM5wxE+xj6mMCDNixd2FVYlf5b7wEA2/9bpiHjy3qi
4MZmFJNcE+XsxReWDTBTZ6VbrjDlqg0=
=M+s4
-----END PGP SIGNATURE-----
Merge tag 'spi-nor/for-6.19' of https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into mtd/next
SPI NOR changes for 6.19
Notable changes:
- Fix SMPT parsing for S25FS-S flash family. They report variable dummy
cycles for reads. This results in the default of 0 being used. This
works for other Infineon chips, but not for the S25FS-S family. They
need 8 dummy cycles. Add fixup hooks to specify that. Also add fixup
hooks to fix incorrect map ID data in SFDP.
- Add support for a bunch of Winbond flashes. Their block protection
information is not discoverable, so they need to have an entry in the
flash tables to describe that.
- Some cleanups for Micron flash support.
- Add support for Micron mt35xu01gbba.
- Some SPI controllers like the Intel one on the PCI bus do not support
the read CR opcode (0x35). Do not use the opcode if the controller
does not support it.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQQTlUWNzXGEo3bFmyIR4drqP028CQUCaSjP+QAKCRAR4drqP028
# CfGsAQC5Vj+FaeQHyY+yywqM5wxE+xj6mMCDNixd2FVYlf5b7wEA2/9bpiHjy3qi
# 4MZmFJNcE+XsxReWDTBTZ6VbrjDlqg0=
# =M+s4
# -----END PGP SIGNATURE-----
# gpg: Signature made jeu. 27 nov. 2025 23:26:01 CET
# gpg: using EDDSA key 1395458DCD7184A376C59B2211E1DAEA3F4DBC09
# gpg: Good signature from "Pratyush Yadav <p.yadav@ti.com>" [expired]
# gpg: aka "Pratyush Yadav <me@yadavpratyush.com>" [expired]
# gpg: p.yadav@ti.com: Verified 5 signatures in the past 3 years. Encrypted 0 messages.
# gpg: me@yadavpratyush.com: Verified 5 signatures in the past 3 years. Encrypted
# 0 messages.
# gpg: Note: This key has expired!
# Primary key fingerprint: 805C 3923 2FBE 108C 49E1 663C F650 3556 C11B 1CCD
# Subkey fingerprint: 1395 458D CD71 84A3 76C5 9B22 11E1 DAEA 3F4D BC09
strncpy() is deprecated [1] for NUL-terminated destination buffers
because it does not guarantee NUL termination. It also unnecessarily
NUL-pads the destination buffer if the source is shorter. Replace it
with sysfs_emit() using the "%.*s" format specifier and supply the
length 'sm_attr->len' to improve sm_attr_show().
Return the number of characters actually written to 'buf' instead of
'sm_attr->len'.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
There are several places where a value of type 'int' is shifted by
lpddr->chipshift. lpddr->chipshift is derived from QINFO geometry and
might reach 31 when QINFO reports a 2 GiB size - the maximum supported by
LPDDR(1) compliant chips. This may cause unexpected sign-extensions when
casting the integer value to the type of 'unsigned long'.
Use '1UL << lpddr->chipshift' and cast 'j' to unsigned long before
shifting so the computation is performed at the destination width.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: c68264711c ("[MTD] LPDDR Command set driver")
Signed-off-by: Ivan Stepchenko <sid@itb.spb.ru>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Fix kernel-doc warnings in docg3.h to avoid build warnings:
Warning: ../drivers/mtd/devices/docg3.h:276 bad line:
Warning: drivers/mtd/devices/docg3.h:299 struct member 'max_block' not
described in 'docg3'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Make both handlers to be shorter and easier to understand.
While at it, unify their style.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Link: https://patch.msgid.link/20251127190031.2998705-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a new VFIO selftest for measuring the time it takes to run
vfio_pci_device_init() in parallel for one or more devices.
This test serves as manual regression test for the performance
improvement of commit e908f58b6b ("vfio/pci: Separate SR-IOV VF
dev_set"). For example, when running this test with 64 VFs under the
same PF:
Before:
$ ./vfio_pci_device_init_perf_test -r vfio_pci_device_init_perf_test.iommufd.init 0000:1a:00.0 0000:1a:00.1 ...
...
Wall time: 6.653234463s
Min init time (per device): 0.101215344s
Max init time (per device): 6.652755941s
Avg init time (per device): 3.377609608s
After:
$ ./vfio_pci_device_init_perf_test -r vfio_pci_device_init_perf_test.iommufd.init 0000:1a:00.0 0000:1a:00.1 ...
...
Wall time: 0.122978332s
Min init time (per device): 0.108121915s
Max init time (per device): 0.122762761s
Avg init time (per device): 0.113816748s
This test does not make any assertions about performance, since any such
assertion is likely to be flaky due to system differences and random
noise. However this test can be fed into automation to detect
regressions, and can be used by developers in the future to measure
performance optimizations.
Suggested-by: Aaron Lewis <aaronlewis@google.com>
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-19-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Eliminate INVALID_IOVA as there are platforms where UINT64_MAX is a
valid iova.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-18-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Split out the contents of libvfio.h into separate header files, but keep
libvfio.h as the top-level include that all tests can use.
Put all new header files into a libvfio/ subdirectory to avoid future
name conflicts in include paths when libvfio is used by other selftests
like KVM.
No functional change intended.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-17-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Move the vfio_selftests_*() helpers into their own file libvfio.c. These
helpers have nothing to do with struct vfio_pci_device, so they don't
make sense in vfio_pci_device.c.
No functional change intended.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-16-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Rename vfio_util.h to libvfio.h to match the name of libvfio.mk.
No functional change intended.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-15-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Drop the struct vfio_pci_device wrappers for IOMMU map/unmap functions
and require tests to directly call iommu_map(), iommu_unmap(), etc. This
results in more concise code, and also makes it clear the map operations
are happening on a struct iommu, not necessarily on a specific device,
especially when multi-device tests are introduced.
Do the same for iova_allocator_init() as that function only needs the
struct iommu, not struct vfio_pci_device.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-14-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Move the IOVA allocator into its own file, to provide better separation
between the allocator and the struct vfio_pci_device helper code.
The allocator could go into iommu.c, but it is standalone enough that a
separate file seems cleaner. This also continues the trend of having a
.c for every major object in VFIO selftests (vfio_pci_device.c,
vfio_pci_driver.c, iommu.c, and now iova_allocator.c).
No functional change intended.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-13-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Move all the IOMMU related library code into their own file iommu.c.
This provides a better separation between the vfio_pci_device helper
code and the iommu code.
No function change intended.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-12-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Rename struct vfio_dma_region to dma_region. This is in preparation for
separating the VFIO PCI device library code from the IOMMU library code.
This name change also better reflects the fact that DMA mappings can be
managed by either VFIO or IOMMUFD. i.e. the "vfio_" prefix is
misleading.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-11-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Upgrade various logging in the VFIO selftests drivers from dev_info() to
dev_err(). All of these logs indicate scenarios that may be unexpected.
For example, the logging during probing indicates matching devices but
that aren't supported by the driver. And the memcpy errors can indicate
a problem if the caller was not trying to do something like exercise I/O
fault handling. Exercising I/O fault handling is certainly a valid thing
to do, but the driver can't infer the caller's expectations, so better
to just log with dev_err().
Suggested-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-10-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Prefix log messages with the device's BDF where relevant. This will help
understanding VFIO selftests logs when tests are run with multiple
devices.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-9-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Eliminate overly chatty logs that are printed during almost every test.
These logs are adding more noise than value. If a test cares about this
information it can log it itself. This is especially true as the VFIO
selftests gains support for multiple devices in a single test (which
multiplies all these logs).
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-8-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Support tests that want to add multiple devices to the same
container/iommufd by decoupling struct vfio_pci_device from
struct iommu.
Multi-devices tests can now put multiple devices in the same
container/iommufd like so:
iommu = iommu_init(iommu_mode);
device1 = vfio_pci_device_init(bdf1, iommu);
device2 = vfio_pci_device_init(bdf2, iommu);
device3 = vfio_pci_device_init(bdf3, iommu);
...
vfio_pci_device_cleanup(device3);
vfio_pci_device_cleanup(device2);
vfio_pci_device_cleanup(device1);
iommu_cleanup(iommu);
To account for the new separation of vfio_pci_device and iommu, update
existing tests to initialize and cleanup a struct iommu.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-7-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Introduce struct iommu, which logically represents either a VFIO
container or an iommufd IOAS, depending on which IOMMU mode is used by
the test.
This will be used in a subsequent commit to allow devices to be added to
the same container/iommufd.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-6-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Rename struct vfio_iommu_mode to struct iommu_mode since the mode can
include iommufd. This also prepares for splitting out all the IOMMU code
into its own structs/helpers/files which are independent from the
vfio_pci_device code.
No function change intended.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-5-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Add support for passing multiple device BDFs to a test via the command
line. This is a prerequisite for multi-device tests.
Single-device tests can continue using vfio_selftests_get_bdf(), which
will continue to return argv[argc - 1] (if it is a BDF string), or the
environment variable $VFIO_SELFTESTS_BDF otherwise.
For multi-device tests, a new helper called vfio_selftests_get_bdfs() is
introduced which will return an array of all BDFs found at the end of
argv[], as well as the number of BDFs found (passed back to the caller
via argument). The array of BDFs returned does not need to be freed by
the caller.
The environment variable VFIO_SELFTESTS_BDF continues to support only a
single BDF for the time being.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-4-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Split run.sh into separate scripts (setup.sh, run.sh, cleanup.sh) to
enable multi-device testing, and prepare for VFIO selftests
automatically detecting which devices to use for testing by storing
device metadata on the filesystem.
- setup.sh takes one or more BDFs as arguments and sets up each device.
Metadata about each device is stored on the filesystem in the
directory:
${TMPDIR:-/tmp}/vfio-selftests-devices
Within this directory is a directory for each BDF, and then files in
those directories that cleanup.sh uses to cleanup the device.
- run.sh runs a selftest by passing it the BDFs of all set up devices.
- cleanup.sh takes zero or more BDFs as arguments and cleans up each
device. If no BDFs are provided, it cleans up all devices.
This split enables multi-device testing by allowing multiple BDFs to be
set up and passed into tests:
For example:
$ tools/testing/selftests/vfio/scripts/setup.sh <BDF1> <BDF2>
$ tools/testing/selftests/vfio/scripts/setup.sh <BDF3>
$ tools/testing/selftests/vfio/scripts/run.sh echo
<BDF1> <BDF2> <BDF3>
$ tools/testing/selftests/vfio/scripts/cleanup.sh
In the future, VFIO selftests can automatically detect set up devices by
inspecting ${TMPDIR:-/tmp}/vfio-selftests-devices. This will avoid the
need for the run.sh script.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-3-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Move run.sh in a new sub-directory scripts/. This directory will be used
to house various helper scripts to be used by humans and automation for
running VFIO selftests.
Opportunistically also switch run.sh from TEST_PROGS_EXTENDED to
TEST_FILES. The former is for actual test executables that are just not
run by default. TEST_FILES is a better fit for helper scripts.
No functional change intended.
Reviewed-by: Alex Mastro <amastro@fb.com>
Tested-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20251126231733.3302983-2-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
- Fix vfio selftests to remove the expectation that the IOMMU
supports a 64-bit IOVA space. These manifest both in the original
set of tests introduced this development cycle in identity mapping
the IOVA to buffer virtual address space, as well as the more
recent boundary testing. Implement facilities for collecting the
valid IOVA ranges from the backend, implement a simple IOVA
allocator, and use the information for determining extents.
(Alex Mastro)
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEQvbATlQL0amee4qQI5ubbjuwiyIFAmkWXwYRHGFsZXhAc2hh
emJvdC5vcmcACgkQI5ubbjuwiyK96w//ep97M1B5RSA4/AIP4j+fovnlM2RVUrPy
RKxVYK+rzftO4Hq8sg1Co3aB68hItbYiw/0BDUgQBFFCEoInQ9zht89tsHhuXq55
lYq9hyYMnp60FLzpX8Fi2HKf8SKTdD+6P1hX5UWZfYExc/tCD/9FPE2QsfUTbnh/
u2aguEp0RhgC8xCcR/5EsGFzcBgioDcTBQq5UQ/5By51nUNvdmHKRHKRC7ZmQfiK
bwFpYseWHRdzdBH2KggNaDZUh0q7Y9+cwL2UndQV5IfwGhGWODztOsVhhoxAAu0n
c6gXYDg34i5i1epPrr8Yvv8trDzMFCRYJi4g8BsLPOBXe8Lr2bWj/4wA1ftdW6Ha
0ii4Gx1UO1vz0KZQBajMHv5pO06lJZshzEQgHr3sYgjaRg8AVTV6hI3IVaty2JWk
DPKPNSGKhjkWvWnx73KFiiepz5zXEL7r7ooFBimtBwFr/5bDB8hfPjpXMh+mhiZu
QW6DV+Mrqg1G1KDCwdHSvbBwH8IvfX/tQbs9eKvGt+6ICpH1GJ1cUr58vjcc6ESi
sJzKI0ceTjGZAhHJogO4xAzhI8H6kwtDHB1ZC9QLHIwbkXFN1m64VjOwwXuHk0HT
559gjqjH0yKNSABwRMV1nKzn9EFnivQn1tAoGkUGSFE9ZI/VfCNNlspPziZEz0z9
u14SILGMqWU=
=ywvT
-----END PGP SIGNATURE-----
Merge tag 'vfio-v6.18-rc6' into v6.19/vfio/next
Merge mainline vfio-selftest updates for ongoing v6.19 work.
Signed-off-by: Alex Williamson <alex@shazbot.org>
Speculative prefetches from CPU to GPU memory until the GPU is
ready after reset can cause harmless corrected RAS events to
be logged on Grace systems. It is thus preferred that the
mapping not be re-established until the GPU is ready post reset.
The GPU readiness can be checked through BAR0 registers similar
to the checking at the time of device probe.
It can take several seconds for the GPU to be ready. So it is
desirable that the time overlaps as much of the VM startup as
possible to reduce impact on the VM bootup time. The GPU
readiness state is thus checked on the first fault/huge_fault
request or read/write access which amortizes the GPU readiness
time.
The first fault and read/write checks the GPU state when the
reset_done flag - which denotes whether the GPU has just been
reset. The memory_lock is taken across map/access to avoid
races with GPU reset.
Also check if the memory is enabled, before waiting for GPU
to be ready. Otherwise the readiness check would block for 30s.
Lastly added PM handling wrapping on read/write access.
Cc: Shameer Kolothum <skolothumtho@nvidia.com>
Cc: Alex Williamson <alex@shazbot.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Vikram Sethi <vsethi@nvidia.com>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Suggested-by: Alex Williamson <alex@shazbot.org>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251127170632.3477-7-ankita@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Introduce a new flag reset_done to notify that the GPU has just
been reset and the mapping to the GPU memory is zapped.
Implement the reset_done handler to set this new variable. It
will be used later in the patches to wait for the GPU memory
to be ready before doing any mapping or access.
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Suggested-by: Alex Williamson <alex@shazbot.org>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251127170632.3477-6-ankita@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Split the function that check for the GPU device being ready on
the probe.
Move the code to wait for the GPU to be ready through BAR0 register
reads to a separate function. This would help reuse the code.
This also fixes a bug where the return status in case of timeout
gets overridden by return from pci_enable_device. With the fix,
a timeout generate an error as initially intended.
Fixes: d85f69d520 ("vfio/nvgrace-gpu: Check the HBM training and C2C link status")
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251127170632.3477-5-ankita@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Remove code duplication in vfio_pci_core_mmap by calling
vfio_pci_core_setup_barmap to perform the bar mapping.
No functional change is intended.
Cc: Donald Dutile <ddutile@redhat.com>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Suggested-by: Alex Williamson <alex@shazbot.org>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251127170632.3477-4-ankita@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
NVIDIA's Grace based systems have large device memory. The device
memory is mapped as VM_PFNMAP in the VMM VMA. The nvgrace-gpu
module could make use of the huge PFNMAP support added in mm [1].
To make use of the huge pfnmap support, fault/huge_fault ops
based mapping mechanism needs to be implemented. Currently nvgrace-gpu
module relies on remap_pfn_range to do the mapping during VM bootup.
Replace it to instead rely on fault and use vfio_pci_vmf_insert_pfn
to setup the mapping.
Moreover to enable huge pfnmap, nvgrace-gpu module is updated by
adding huge_fault ops implementation. The implementation establishes
mapping according to the order request. Note that if the PFN or the
VMA address is unaligned to the order, the mapping fallbacks to
the PTE level.
Link: https://lore.kernel.org/all/20240826204353.2228736-1-peterx@redhat.com/ [1]
Cc: Shameer Kolothum <skolothumtho@nvidia.com>
Cc: Alex Williamson <alex@shazbot.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Vikram Sethi <vsethi@nvidia.com>
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251127170632.3477-3-ankita@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Refactor vfio_pci_mmap_huge_fault to take out the implementation
to map the VMA to the PTE/PMD/PUD as a separate function.
Export the new function to be used by nvgrace-gpu module.
Move the alignment check code to verify that pfn and VMA VA is
aligned to the page order to the header file and make it inline.
No functional change is intended.
Cc: Shameer Kolothum <skolothumtho@nvidia.com>
Cc: Alex Williamson <alex@shazbot.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251127170632.3477-2-ankita@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
fill_sg_entry() splits large DMA buffers into multiple scatter-gather
entries, each holding up to UINT_MAX bytes. When calculating the DMA
address for entries beyond the second one, the expression (i * UINT_MAX)
causes integer overflow due to 32-bit arithmetic.
This manifests when the input arg length >= 8 GiB results in looping for
i >= 2.
Fix by casting i to dma_addr_t before multiplication.
Fixes: 3aa31a8bb1 ("dma-buf: provide phys_vec to scatter-gather mapping routine")
Signed-off-by: Alex Mastro <amastro@fb.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Leon Romanovsky <leon@kernel.org>
Link: https://lore.kernel.org/r/20251125-dma-buf-overflow-v1-1-b70ea1e6c4ba@fb.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Thanks to a device generating an ACS violation during bus reset,
lockdep reported the following circular locking issue:
CPU0: SET_IRQS (MSI/X): holds igate, acquires memory_lock
CPU1: HOT_RESET: holds memory_lock, acquires pci_bus_sem
CPU2: AER: holds pci_bus_sem, acquires igate
This results in a potential 3-way deadlock.
Remove the pci_bus_sem->igate leg of the triangle by using RCU
to peek at the eventfd rather than locking it with igate.
Fixes: 3be3a074cf ("vfio-pci: Don't use device_lock around AER interrupt setup")
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20251124223623.2770706-1-alex@shazbot.org
Signed-off-by: Alex Williamson <alex@shazbot.org>
In max16065_current_show, data->curr_sense is read twice: once for the
error check and again for the calculation. Since
i2c_smbus_read_byte_data returns negative error codes on failure, if the
data changes to an error code between the check and the use, ADC_TO_CURR
results in an incorrect calculation.
Read data->curr_sense into a local variable to ensure consistency. Note
that data->curr_gain is constant and safe to access directly.
This aligns max16065_current_show with max16065_input_show, which
already uses a local variable for the same reason.
Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
Fixes: f5bae2642e ("hwmon: Driver for MAX16065 System Manager and compatibles")
Cc: stable@vger.kernel.org
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://lore.kernel.org/r/20251128124709.3876-1-hanguidong02@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The macros FAN_FROM_REG and TEMP_FROM_REG evaluate their arguments
multiple times. When used in lockless contexts involving shared driver
data, this causes Time-of-Check to Time-of-Use (TOCTOU) race
conditions.
Convert the macros to static functions. This guarantees that arguments
are evaluated only once (pass-by-value), preventing the race
conditions.
Adhere to the principle of minimal changes by only converting macros
that evaluate arguments multiple times and are used in lockless
contexts.
Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
Fixes: 85f03bccd6 ("hwmon: Add support for Winbond W83L786NG/NR")
Cc: stable@vger.kernel.org
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://lore.kernel.org/r/20251128123816.3670-1-hanguidong02@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The manuals of 2K2000 says both BIT_CTRL_MODE and BYTE_CTRL_MODE are
supported but the latter is recommended. Also on 2K3000, per the ACPI
DSDT the GPIO controller is compatible with 2K2000, but it fails to
operate GPIOs 62 and 63 (and maybe others) using BIT_CTRL_MODE.
Using BYTE_CTRL_MODE also makes those 2K3000 GPIOs work.
Fixes: 3feb70a617 ("gpio: loongson: add more gpio chip support")
Cc: stable@vger.kernel.org
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/20251128075033.255821-1-xry111@xry111.site
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add a ':' to the end of struct member names to prevent kernel-doc
warnings:
Warning: include/linux/gpio/regmap.h:108 struct member 'regmap_irq_line'
not described in 'gpio_regmap_config'
Warning: include/linux/gpio/regmap.h:108 struct member 'regmap_irq_flags'
not described in 'gpio_regmap_config'
Fixes: 553b75d4bf ("gpio: regmap: Allow to allocate regmap-irq device")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20251128062739.845403-1-rdunlap@infradead.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Discovered by Atuin - Automated Vulnerability Discovery Engine.
The 'len' variable is calculated as 'min(32, trans->len + 1)',
which includes the 1-byte command header.
When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len'
as the length is incorrect because:
1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size
'trans->len', i.e., 'len - 1' in this context).
2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is
CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1
overflows the buffer.
Fix this by copying 'len - 1' bytes.
Fixes: 8846739f52 ("spi: add ch341a usb2spi driver")
Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
Link: https://patch.msgid.link/20251128160630.0f922c45ec6084a46fb57099@linux.dev
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_pm_runtime_enable() can fail due to memory allocation failures.
The current code ignores its return value and proceeds with
pm_runtime_resume_and_get(), which may operate on incorrectly
initialized runtime PM state.
Check the return value of devm_pm_runtime_enable() and return the
error code if it fails.
Fixes: 6a2277a0eb ("mtd: rawnand: renesas: Use runtime PM instead of the raw clock API")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
If the IOVA is limited to less than 48 the page table will be constructed
with a 3 level configuration which is unsupported by hardware.
Like the second stage the caller needs to pass in both the top_level an
the vasz to specify a table that has more levels than required to hold the
IOVA range.
Fixes: 6cbc09b771 ("iommu/vt-d: Restore previous domain::aperture_end calculation")
Reported-by: Calvin Owens <calvin@wbinvd.org>
Closes: https://lore.kernel.org/r/8f257d2651eb8a4358fcbd47b0145002e5f1d638.1764237717.git.calvin@wbinvd.org
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Tested-by: Calvin Owens <calvin@wbinvd.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
VT-d second stage HW specifies both the maximum IOVA and the supported
table walk starting points. Weirdly there is HW that only supports a 4
level walk but has a maximum IOVA that only needs 3.
The current code miscalculates this and creates a wrongly sized page table
which ultimately fails the compatibility check for number of levels.
This is fixed by allowing the page table to be created with both a vasz
and top_level input. The vasz will set the aperture for the domain while
the top_level will set the page table geometry.
Add top_level to vtdss and correct the logic in VT-d to generate the right
top_level and vasz from mgaw and sagaw.
Fixes: d373449d8e ("iommu/vt-d: Use the generic iommu page table")
Reported-by: Calvin Owens <calvin@wbinvd.org>
Closes: https://lore.kernel.org/r/8f257d2651eb8a4358fcbd47b0145002e5f1d638.1764237717.git.calvin@wbinvd.org
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Tested-by: Calvin Owens <calvin@wbinvd.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add the missing forward declarations and includes so it does not have
implicit dependencies. mem_encrypt.h is a public header imported by
drivers. Users should not have to guess what include files are needed.
Resolves a kbuild splat:
In file included from drivers/iommu/generic_pt/fmt/iommu_amdv1.c:15:
In file included from drivers/iommu/generic_pt/fmt/iommu_template.h:36:
In file included from drivers/iommu/generic_pt/fmt/amdv1.h:23:
In file included from include/linux/mem_encrypt.h:17:
>> arch/powerpc/include/asm/mem_encrypt.h:13:49: warning: declaration of 'struct device' will not be visible outside of this function [-Wvisibility]
13 | static inline bool force_dma_unencrypted(struct device *dev)
Fixes: 879ced2bab ("iommupt: Add the AMD IOMMU v1 page table format")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511161358.rS5pSb3U-lkp@intel.com/
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
There is no point in asking the user about the Generic Radix Page
Table API:
- All IOMMU drivers that use this API already select GENERIC_PT when
needed,
- Most users probably do not know what to answer anyway.
Fixes: 7c5b184db7 ("genpt: Generic Page Table base API")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
While reading some other stuff, I noticed that this driver may
be improved. Here is the set of refactoring and cleaning it up.
regulator_supply_alias_list was accessed without any locking in
regulator_supply_alias(), regulator_register_supply_alias(), and
regulator_unregister_supply_alias(). Concurrent registration,
unregistration and lookups can race, leading to:
1 use-after-free if an alias entry is removed while being read,
2 duplicate entries when two threads register the same alias,
3 inconsistent alias mappings observed by consumers.
Protect all traversals, insertions and deletions on
regulator_supply_alias_list with the existing regulator_list_mutex.
Fixes: a06ccd9c37 ("regulator: core: Add ability to create a lookup alias for supply")
Signed-off-by: sparkhuang <huangshaobo3@xiaomi.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251127025716.5440-1-huangshaobo3@xiaomi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver uses DMA but does not mark it as a prerequisite in
Kconfig. As it is also defined with COMPILE_TEST, autobuilders complain
about certain symbols not being available when linking on architectures
without DMA support (?) like sh.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511071114.8WeW2GZK-lkp@intel.com
Cc: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
Suggested-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Merge series from Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>:
Airoha EN7523 snfi controller almost identical to AN7581 one, so the same
driver can be used. The only known difference appears in the very specific
boot conditions, when attached serial console force EN7523 SoC boots
in undocumented (reserved) mode. In this mode dma reading of the flash
works incorrectly.
This patch series:
* add support of EN7523 SoC
* add spinand node to en7523 dts (so spinand flash finally becomes usable)
* updates dt-bindings to mark driver as compatible with en7523
* disable dma usage to prevent possible data damage if booting in
reserved mode was detected.
The i2c regmap allocated during probe is never freed.
Switch to using the device managed allocator so that the regmap is
released on probe failures (e.g. probe deferral) and on driver unbind.
Fixes: 3a2a8cc3fe ("hwmon: (max6697) Convert to use regmap")
Cc: stable@vger.kernel.org # 6.12
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20251127134351.1585-1-johan@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Static declaration by default are 0 or NULL, no need to initialise
them explicitly. Remove unneeded PM related macro.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Link: https://patch.msgid.link/20251126075558.2035012-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a temporary variable to keep a pointer to struct device.
Utilise it where it makes sense.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Link: https://patch.msgid.link/20251126075558.2035012-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
First of all, the convention in the kernel that we do not issue
error messages for -ENOMEM. Second, it's ignored by dev_err_probe().
Replace dead code by a simple return statement.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Link: https://patch.msgid.link/20251126075558.2035012-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
min_t(int, a, b) casts an 'unsigned int' to 'int'. This might lead
to the cases when big number is wrongly chosen. On the other hand,
the SPI transfer length is unsigned and driver uses signed type for
an unknown reason. Change the type of the transfer length to be
unsigned and convert use min() instead of min_t().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: David Laight <david.laight.linux@gmail.com>
Reviewed-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Link: https://patch.msgid.link/20251126075558.2035012-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
gcc 13, in some cases, gets confused if the __builtin_constant_p() is
inside the switch. It thinks that bitnr can have the value max+1 and
fails. Lift the check outside the switch to avoid it.
Fixes: ef7bfe5bbf ("iommupt/x86: Support SW bits and permit PT_FEAT_DMA_INCOHERENT")
Fixes: 5448c1558f ("iommupt: Add the Intel VT-d second stage page table format")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511242012.I7g504Ab-lkp@intel.com/
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add dt-bindings documentation of SPI NAND controller
for Airoha EN7523 SoC platform.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251125234047.1101985-3-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Airoha EN7523 specific bug
--------------------------
We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of its bootstrap pins. On the EN7523
SoC this may lead to booting in RESERVED boot mode.
It was found that some flashes operates incorrectly in RESERVED mode.
Micron and Skyhigh flashes are definitely affected by the issue,
Winbond flashes are not affected.
Details:
--------
DMA reading of odd pages on affected flashes operates incorrectly. Page
reading offset (start of the page) on hardware level is replaced by 0x10.
Thus results in incorrect data reading. As result OS loading becomes
impossible.
Usage of UBI make things even worse. On attaching, UBI will detects
corruptions (because of wrong reading of odd pages) and will try to
recover. For recovering UBI will erase and write 'damaged' blocks with
a valid information. This will destroy all UBI data.
Non-DMA reading is OK.
This patch detects booting in reserved mode, turn off DMA and print big
fat warning.
It's worth noting that the boot configuration is preserved across reboots.
Therefore, to boot normally, you should do the following:
- disconnect the serial console from the board,
- power cycle the board.
Fixes: a403997c12 ("spi: airoha: add SPI-NAND Flash controller driver")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20251125234047.1101985-2-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
The rzg2l_gpt_config() tests the rzg2l_gpt->period_tick variable when
both channels of a hardware channel are in use. This check is not valid
if rzg2l_gpt_config() is called after disabling all the channels, as it
tests against the cached value. Hence, allow checking and setting the
cached value only if the sibling channel is enabled.
While at it, drop else after return statement to fix the check patch
warning.
Cc: stable@kernel.org
Fixes: 061f087f5d ("pwm: Add support for RZ/G2L GPT")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20251126104308.142302-1-biju.das.jz@bp.renesas.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The prefetch instruction is meant to speed up access to memory referenced
by its address argument. In the bng_re code path, it has no effect,
because the pointer refers to a function that is executed immediately
afterward.
The issue was identified due to the following kbuild compilation error:
drivers/infiniband/hw/bng_re/bng_fw.c: In function 'bng_re_creq_irq':
drivers/infiniband/hw/bng_re/bng_fw.c:278:9: error: implicit
declaration of function 'prefetch' [-Wimplicit-function-declaration]
278 | prefetch(bng_re_get_qe(hwq, sw_cons, NULL));
| ^~~~~~~~
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511260607.Kuxn4NnN-lkp@intel.com/
Fixes: 4f830cd8d7 ("RDMA/bng_re: Add infrastructure for enabling Firmware channel")
Link: https://patch.msgid.link/20251126-remove-prefetch-v1-1-fcac22007ea7@nvidia.com
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
When building for a platform without CONFIG_PM_SLEEP, such as s390,
there are two unused function warnings:
drivers/video/backlight/aw99706.c:436:12: error: 'aw99706_resume' defined but not used [-Werror=unused-function]
436 | static int aw99706_resume(struct device *dev)
| ^~~~~~~~~~~~~~
drivers/video/backlight/aw99706.c:429:12: error: 'aw99706_suspend' defined but not used [-Werror=unused-function]
429 | static int aw99706_suspend(struct device *dev)
| ^~~~~~~~~~~~~~~
SET_SYSTEM_SLEEP_PM_OPS, used within SIMPLE_DEV_PM_OPS, expands to
nothing when CONFIG_PM_SLEEP is not set, so these functions are
completely unused in this configuration.
SIMPLE_DEV_PM_OPS is deprecated in favor of DEFINE_SIMPLE_DEV_PM_OPS,
which avoids this issue by using pm_sleep_ptr to make these callbacks
NULL when CONFIG_PM_SLEEP is unset while making the callback functions
always appear used to the compiler regardless of configuration. Switch
to DEFINE_SIMPLE_DEV_PM_OPS for aw99706_pm_ops to clear up the warning.
Additionally, wrap the pointer to aw99706_pm_ops in pm_ptr() in
aw99706_i2c_driver to ensure that the structure is completely eliminated
in configurations without CONFIG_PM.
Fixes: 88a8e9b49ee8 ("backlight: aw99706: Add support for Awinic AW99706 backlight")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20251120-backlight-aw99706-fix-unused-pm-functions-v1-1-8b9c17c4e783@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
There's an unexpected interaction between the reset-gpio driver and the
shared GPIO support. The reset-gpio device is an auxiliary device that's
created dynamically and fulfills a similar role to the gpio-shared-proxy
driver but is limited in scope to just supporting the "reset-gpios"
property.
The shared GPIO core code does not take into account that the machine
lookup entry we create when scanning the device-tree must connect the
reset-gpio device - that is the actual consumer of the GPIO and not the
consumer defined on the device tree, which in turn consumes the shared
reset control exposed by the reset-gpio device - to the GPIO controller.
We also must not skip the gpio-shared-proxy driver as it's possible that
a shared GPIO may be used by one consumer as a reset-gpios going through
the reset-gpio device and another that uses GPIOLIB.
We need to make it a special case handled in gpiolib-shared.c. Add a new
function - gpio_shared_dev_is_reset_gpio() - whose role it is to verify
if a non-matching consumer of a shared pin is a reset-gpio device and
make sure it's the right one for this pin. To that end make sure that
its parent is the GPIO controller in question and that the fwnode we
identified as sharing the pin references that controller via the
"reset-gpios" property.
Only include that code if the reset-gpio driver is enabled.
Fixes: a060b8c511 ("gpiolib: implement low-level, shared GPIO support")
Reported-by: Val Packett <val@packett.cool>
Closes: https://lore.kernel.org/all/3b5d9df5-934d-4591-8827-6c9573a6f7ba@packett.cool/
Tested-by: Val Packett <val@packett.cool>
Tested-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20251125-gpiolib-shared-reset-gpio-fix-v2-1-4eb6fa41f1dd@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
test just uses vhost features with no change,
but people tend to copy/paste code, so let's
add our own define.
Message-ID: <23ca04512a800ee8b3594482492e536020931340.1764225384.git.mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio pci uses word to mean "16 bits". mmio uses it to mean
"32 bits".
To avoid confusion, let's avoid the term in core virtio
altogether. Just say U64 to mean "64 bit".
Fixes: e7d4c1c5a5 ("virtio: introduce extended features")
Cc: Paolo Abeni <pabeni@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-ID: <ad53b7b6be87fc524f45abaeca0bb05fb3633397.1764225384.git.mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251107154917.313090-3-marco.crivellari@suse.com>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251107154917.313090-2-marco.crivellari@suse.com>
Use %pe instead of %ps when printing ERR_PTR() values. %ps is intended
for string pointers, while %pe correctly prints symbolic error names
for error pointers returned via ERR_PTR().
This shows the returned error value more clearly.
Fixes: 67f27b8b3a ("pds_vdpa: subscribe to the pds_core events")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Reviewed-by: Brett Creeley <brett.creeley@amd.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251018174705.1511982-1-alok.a.tiwari@oracle.com>
If we fail to attach to a cgroup we are leaking the id. This adds
a new goto to free the id.
Fixes: 7d9896e9f6 ("vhost: Reintroduce kthread API and add mode selection")
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251101194358.13605-1-michael.christie@oracle.com>
pci_get_device() will increase the reference count for the returned
pci_dev, and also decrease the reference count for the input parameter
from if it is not NULL.
If we break the loop in with 'vf_pdev' not NULL. We
need to call pci_dev_put() to decrease the reference count.
Found via static anlaysis and this is similar to commit c508eb042d
("perf/x86/intel/uncore: Fix reference count leak in sad_cfg_iio_topology()")
Fixes: 8b6c724cda ("virtio: vdpa: vDPA driver for Marvell OCTEON DPU devices")
Cc: stable@vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251027060737.33815-1-linmq006@gmail.com>
When query_virtqueues() fails, the error log prints the variable err
instead of cmd->err. Since err may still be zero at this point, the
log message can misleadingly report a success value 0 even though the
command actually failed.
Even worse, once err is set to the first failure, subsequent logs
print that same stale value. This makes the error reporting appear
one step behind the actual failing queue index, which is confusing
and misleading.
Fix the log to report cmd->err, which reflects the real failure code
returned by the firmware.
Fixes: 1fcdf43ea6 ("vdpa/mlx5: Use async API for vq query command")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20250929134258.80956-1-alok.a.tiwari@oracle.com>
@free will free the map handle not sync it. Fix the doc to match.
Fixes: bee8c7c24b ("virtio: introduce map ops in virtio core")
Message-Id: <f6ff1c7aff8401900bf362007d7fb52dfdb6a15b.1763026134.git.mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Rewrite the comment for better grammar and clarity.
Fixes: 75a0a52be3 ("virtio: introduce an API to set affinity for a virtqueue")
Message-Id: <e317e91bd43b070e5eaec0ebbe60c5749d02e2dd.1763026134.git.mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Remove colons after "Returns" in virtio_map_ops function
documentation - both to avoid triggering an htmldoc warning
and for consistency with virtio_config_ops.
This affects map_page, alloc, need_sync, and max_mapping_size.
Fixes: bee8c7c24b ("virtio: introduce map ops in virtio core")
Message-Id: <c262893fa21f4b1265147ef864574a9bd173348f.1763026134.git.mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Fix grammar issues in the virtio_map_ops docs:
- missing article before "transport"
- "implements" -> "implement" to match subject
Fixes: bee8c7c24b ("virtio: introduce map ops in virtio core")
Message-Id: <3f7bcae5a984f14b72e67e82572b110acb06fa7e.1763026134.git.mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Fix grammar in the description of @ctx
Fixes: c502eb85c3 ("virtio: introduce virtio_queue_info struct and find_vqs_info() config op")
Message-Id: <a5cf2b92573200bdb1c1927e559d3930d61a4af2.1763026134.git.mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The finalize_features documentation uses a tab between words.
Use space instead.
Fixes: d16c0cd273 ("docs: driver-api: virtio: virtio on Linux")
Message-Id: <39d7685c82848dc6a876d175e33a1407f6ab3fc1.1763026134.git.mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
"coherenct" -> "coherent"
Fixes: 8b4ec69d7e ("virtio: harden vring IRQ")
Message-Id: <db286e9a65449347f6584e68c9960fd5ded2b4b0.1763026134.git.mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Documentation build reported:
WARNING: ./drivers/virtio/virtio_ring.c:3174 function parameter 'vaddr' not described in 'virtqueue_map_free_coherent'
WARNING: ./drivers/virtio/virtio_ring.c:3308 expecting prototype for virtqueue_mapping_error(). Prototype was for virtqueue_map_mapping_error() instead
The kernel-doc block for virtqueue_map_free_coherent() omitted the @vaddr parameter, and
the kernel-doc header for virtqueue_map_mapping_error() used the wrong function name
(virtqueue_mapping_error) instead of the actual function name.
This change updates:
- the function name in the comment to virtqueue_map_mapping_error()
- adds the missing @vaddr description in the comment for virtqueue_map_free_coherent()
Fixes: b41cb3bcf6 ("virtio: rename dma helpers")
Signed-off-by: Kriish Sharma <kriish.sharma2006@gmail.com>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20251110202920.2250244-1-kriish.sharma2006@gmail.com>
virtio_vdpa_set_status() is declared as returning void, but it used
"return vdpa_set_status()" Since vdpa_set_status() also returns
void, the return statement is unnecessary and misleading.
Remove it.
Fixes: c043b4a8cf ("virtio: introduce a vDPA based transport")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Message-Id: <20251001191653.1713923-1-alok.a.tiwari@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Starting with commit 69a8b62a7a ("riscv: acpi: avoid errors caused by
probing DT devices when ACPI is used"), riscv images no longer populate
devicetree if ACPI is enabled. This causes unit tests to fail which require
the root node to be set.
# Subtest: of_dtb
# module: of_test
1..2
# of_dtb_root_node_found_by_path: EXPECTATION FAILED at drivers/of/of_test.c:21
Expected np is not null, but is
# of_dtb_root_node_found_by_path: pass:0 fail:1 skip:0 total:1
not ok 1 of_dtb_root_node_found_by_path
# of_dtb_root_node_populates_of_root: EXPECTATION FAILED at drivers/of/of_test.c:31
Expected of_root is not null, but is
# of_dtb_root_node_populates_of_root: pass:0 fail:1 skip:0 total:1
not ok 2 of_dtb_root_node_populates_of_root
Skip those tests for RISCV if the root node is not populated.
Fixes: 69a8b62a7a ("riscv: acpi: avoid errors caused by probing DT devices when ACPI is used")
Cc: Han Gao <rabenda.cn@gmail.com>
Cc: Paul Walmsley <pjw@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Paul Walmsley <pjw@kernel.org> # arch/riscv
Link: https://patch.msgid.link/20251023160415.705294-1-linux@roeck-us.net
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node and matching against it with
new of_machine_device_match() helper.
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-11-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node, matching against it and getting
the match data with new of_machine_get_match_data() helper.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-10-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node, matching against it and getting
the match data with new of_machine_get_match_data() helper.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-9-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node, matching against it and getting
the match data with new of_machine_get_match_data() helper.
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-8-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node, matching against it and getting
the match data with new of_machine_get_match_data() helper.
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-7-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node and matching against it with
new of_machine_device_match() helper.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-6-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node and matching against it with
new of_machine_device_match() helper.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-5-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node and matching against it with
new of_machine_device_match() helper.
Acked-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-4-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node, matching against it and getting
the match data with new of_machine_get_match_data() helper.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-3-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Replace open-coded getting root OF node, matching against it and getting
the match data with two new helpers: of_machine_get_match_data() and
of_machine_device_match().
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-2-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Several drivers duplicate same code for getting reference to the root
node, matching it against 'struct of_device_id' table and getting out
the match data from the table entry.
There is a of_machine_compatible_match() wrapper but it takes array of
strings, which is not suitable for many drivers since they want the
driver data associated with each compatible.
Add two wrappers, similar to existing of_device_get_match_data():
1. of_machine_device_match() doing only matching against 'struct
of_device_id' and returning bool.
2. of_machine_get_match_data() doing the matching and returning
associated driver data for found compatible.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-1-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Document the RSPI controller on the Renesas RZ/V2N SoC. The block is
compatible with the RSPI implementation found on the RZ/V2H(P) family.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251126131619.136605-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>:
Use container_of_const(), which is preferred over container_of(), when
the argument 'ptr' and returned pointer are already const, for better
code safety and readability.
Some drivers already have const everywhere, so container_of_const can be
directly used. In few other drivers, the final pointer can be constified
that way.
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-8-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-7-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-6-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-5-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-4-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-3-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-2-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use container_of_const(), which is preferred over container_of(), when
the argument 'ptr' and returned pointer are already const, for better
code safety and readability.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-1-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Jason Gunthorpe says:
====================
This series is the start of adding full DMABUF support to
iommufd. Currently it is limited to only work with VFIO's DMABUF exporter.
It sits on top of Leon's series to add a DMABUF exporter to VFIO:
https://lore.kernel.org/all/20251120-dmabuf-vfio-v9-0-d7f71607f371@nvidia.com/
The existing IOMMU_IOAS_MAP_FILE is enhanced to detect DMABUF fd's, but
otherwise works the same as it does today for a memfd. The user can select
a slice of the FD to map into the ioas and if the underliyng alignment
requirements are met it will be placed in the iommu_domain.
Though limited, it is enough to allow a VMM like QEMU to connect MMIO BAR
memory from VFIO to an iommu_domain controlled by iommufd. This is used
for PCI Peer to Peer support in VMs, and is the last feature that the VFIO
type 1 container has that iommufd couldn't do.
The VFIO type1 version extracts raw PFNs from VMAs, which has no lifetime
control and is a use-after-free security problem.
Instead iommufd relies on revokable DMABUFs. Whenever VFIO thinks there
should be no access to the MMIO it can shoot down the mapping in iommufd
which will unmap it from the iommu_domain. There is no automatic remap,
this is a safety protocol so the kernel doesn't get stuck. Userspace is
expected to know it is doing something that will revoke the dmabuf and
map/unmap it around the activity. Eg when QEMU goes to issue FLR it should
do the map/unmap to iommufd.
Since DMABUF is missing some key general features for this use case it
relies on a "private interconnect" between VFIO and iommufd via the
vfio_pci_dma_buf_iommufd_map() call.
The call confirms the DMABUF has revoke semantics and delivers a phys_addr
for the memory suitable for use with iommu_map().
Medium term there is a desire to expand the supported DMABUFs to include
GPU drivers to support DPDK/SPDK type use cases so future series will work
to add a general concept of revoke and a general negotiation of
interconnect to remove vfio_pci_dma_buf_iommufd_map().
I also plan another series to modify iommufd's vfio_compat to
transparently pull a dmabuf out of a VFIO VMA to emulate more of the uAPI
of type1.
The latest series for interconnect negotation to exchange a phys_addr is:
https://lore.kernel.org/r/20251027044712.1676175-1-vivek.kasireddy@intel.com
And the discussion for design of revoke is here:
https://lore.kernel.org/dri-devel/20250114173103.GE5556@nvidia.com/
====================
Based on a shared branch with vfio.
* iommufd_dmabuf:
iommufd/selftest: Add some tests for the dmabuf flow
iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE
iommufd: Have iopt_map_file_pages convert the fd to a file
iommufd: Have pfn_reader process DMABUF iopt_pages
iommufd: Allow MMIO pages in a batch
iommufd: Allow a DMABUF to be revoked
iommufd: Do not map/unmap revoked DMABUFs
iommufd: Add DMABUF to iopt_pages
vfio/pci: Add vfio_pci_dma_buf_iommufd_map()
vfio/nvgrace: Support get_dmabuf_phys
vfio/pci: Add dma-buf export support for MMIO regions
vfio/pci: Enable peer-to-peer DMA transactions by default
vfio/pci: Share the core device pointer while invoking feature functions
vfio: Export vfio device get and put registration helpers
dma-buf: provide phys_vec to scatter-gather mapping routine
PCI/P2PDMA: Document DMABUF model
PCI/P2PDMA: Provide an access to pci_p2pdma_map_type() function
PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation
PCI/P2PDMA: Simplify bus address mapping API
PCI/P2PDMA: Separate the mmap() support from the core logic
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
A vDEVICE has been a hard requirement for attaching a nested domain to the
device. This makes sense when installing a guest STE, since a vSID must be
present and given to the kernel during the vDEVICE allocation.
But, when CR0.SMMUEN is disabled, VM doesn't really need a vSID to program
the vSMMU behavior as GBPA will take effect, in which case the vSTE in the
nested domain could have carried the bypass or abort configuration in GBPA
register. Thus, having such a hard requirement doesn't work well for GBPA.
Skip vmaster allocation in arm_smmu_attach_prepare_vmaster() for an abort
or bypass vSTE. Note that device on this attachment won't report vevents.
Update the uAPI doc accordingly.
Link: https://patch.msgid.link/r/20251103172755.2026145-1-nicolinc@nvidia.com
Tested-by: Shameer Kolothum <skolothumtho@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
In w83781d_isa_found() there is REALLY_SLOW_IO defined around some port
accesses, probably in order to wait between multiple accesses.
Unfortunately this isn't making any difference compared to not having
this define since more than a decade, as REALLY_SLOW_IO needs to be
defined while "#include <asm/io.h>" is called to have an effect.
As there seem not to be any outstanding issues in spite of this having
no effect, just drop the "#define" and add a remark to the related
comment.
Signed-off-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20251126162018.5676-4-jgross@suse.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In lm78_isa_found() there is REALLY_SLOW_IO defined around some port
accesses, probably in order to wait between multiple accesses.
Unfortunately this isn't making any difference compared to not having
this define since more than a decade, as REALLY_SLOW_IO needs to be
defined while "#include <asm/io.h>" is called to have an effect.
As there seem not to be any outstanding issues in spite of this having
no effect, just drop the "#define" and add a remark to the related
comment.
Signed-off-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20251126162018.5676-3-jgross@suse.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In sy7636a_sensor_probe(), regulator_enable() is called but if
devm_hwmon_device_register_with_info() fails, the function returns
without calling regulator_disable(), leaving the regulator enabled
and leaking the reference count.
Switch to devm_regulator_get_enable() to automatically
manage the regulator resource.
Fixes: de34a40532 ("hwmon: sy7636a: Add temperature driver for sy7636a")
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://lore.kernel.org/r/20251126162602.2086-1-vulab@iscas.ac.cn
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The scroll resolution multipliers are set in the context of
hidinput_connect(), which is only called at probe time: when the host
changes the value on the device with a SET_REPORT(FEATURE), and the device
accepts it, these multipliers are stored on the host side, and used to
calculate the final scroll event values sent to userspace.
After a USB suspend, the resume operation on many hubs and chipsets
involve a USB reset signal as well. A reset on the device side clears all
previous state information, including the value of the multiplier report.
This reset is not handled by the multiplier handling logic, so what ends up
happening is the host is still expecting high-resolution scroll events,
but the device is reset to default resolution, making the effective,
user-perceived scroll speed incredibly slow.
The solution is to renegotiate the multiplier selection after each reset.
This is not the only bug related to the high-resolution scrolling
implementation in the kernel (the other one is
https://bugzilla.kernel.org/show_bug.cgi?id=220144), but for this one,
there is no device side workaround for, leading to poor user experience with our product:
https://github.com/UltimateHackingKeyboard/firmware/issues/1155https://github.com/UltimateHackingKeyboard/firmware/issues/1261https://github.com/UltimateHackingKeyboard/firmware/pull/1355
This patch was tested by an affected user and has been reported to
fix the issue (see discussion in 1355).
Signed-off-by: Benedek Kupper <kupper.benedek@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The mouse portion of the device's Report Descriptor declares 5 buttons but only
declares 3 usages (Button 1 through Button 3). As a result events for the 2
side buttons are not generated.
Detect and repair the Report Descriptor if necessary by changing the Usage
Maximum value from Button 3 to Button 5.
[jkosina@suse.com: standardize changelog a little bit]
Reported-by: Artem <temabiill@gmail.com>
Closes: https://lore.kernel.org/all/CADYkRmrfhRf6VmQjc+su+mepyv=TsHc+aMcL6ryRZ5HTZ8pyFg@mail.gmail.com/
Signed-off-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
Tested-by: Artem <temabiill@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The macro FAN_FROM_REG evaluates its arguments multiple times. When used
in lockless contexts involving shared driver data, this causes
Time-of-Check to Time-of-Use (TOCTOU) race conditions.
Convert the macro to a static function. This guarantees that arguments
are evaluated only once (pass-by-value), preventing the race
conditions.
Adhere to the principle of minimal changes by only converting macros
that evaluate arguments multiple times and are used in lockless
contexts.
Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://lore.kernel.org/r/20251126113828.10003-1-hanguidong02@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function fan_show checks shared data for zero or invalid values
before using it as a divisor. These accesses are currently lockless. If
the data changes to zero between the check and the division, it causes a
divide-by-zero error.
Explicitly acquire the update lock around these checks and calculations
to ensure the data remains stable, preventing Time-of-Check to
Time-of-Use (TOCTOU) race conditions.
Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://lore.kernel.org/r/20251126114047.10039-1-hanguidong02@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The macro FAN_FROM_REG evaluates its arguments multiple times. When used
in lockless contexts involving shared driver data, this causes
Time-of-Check to Time-of-Use (TOCTOU) race conditions.
Convert the macro to a static function. This guarantees that arguments
are evaluated only once (pass-by-value), preventing the race
conditions.
Adhere to the principle of minimal changes by only converting macros
that evaluate arguments multiple times and are used in lockless
contexts.
Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://lore.kernel.org/r/20251126113542.9968-1-hanguidong02@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Since commit 6f20d32612 ("HID: logitech-dj: Fix error handling in
logi_dj_recv_switch_to_dj_mode()") logi_dj_recv_switch_to_dj_mode()
will return an error when the hid_hw_raw_request() call to enable
[dis]connect events fails.
This can happen when used with a KVM like the Aten CS1784a and the PC
does not have the KVM focus when probe() runs, which causes probe() to
fail after which the receiver will simply not work.
The logi_dj_recv_query_paired_devices() call done at the end of probe()
already ignores any errors for the KVM without focus case. When focus is
restored and an input report is received this will trigger
logi_dj_recv_queue_unknown_work() which retries the query_paired_devices()
call from a workqueue.
To fix the probe() failure let it ignore logi_dj_recv_switch_to_dj_mode()
errors too, track if a successful logi_dj_recv_switch_to_dj_mode() was
done and retry if necessary from logi_dj_recv_queue_unknown_work().
Queurying paired devices while not in dj-mode is not useful and this
will be redone after the unknown work has retried setting dj-mode,
so skip queurying paired devices when not in dj-mode yet.
The new bool to track successful setting of the dj-mode will also cause
setting dj-mode to be retried from the unknown work, if setting dj-mode
failed after a reset_resume.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
logi_dj_recv_query_paired_devices() and logi_dj_recv_switch_to_dj_mode()
both have 2 callers which all log an error if the function fails. Move
the error logging to inside these 2 functions to remove the duplicated
error logging in the callers.
While at it also move the logi_dj_recv_send_report() call error handling
in logi_dj_recv_switch_to_dj_mode() to directly after the call. That call
only fails if the report cannot be found and in that case it does nothing,
so the msleep() is not necessary on failures.
Fixes: 6f20d32612 ("HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode()")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The Logitech G Pro X Superlight 2 has a lightspeed receiver with a
product id of 0xc54d, this receiver behaves like the receiver used in
the original Logitech G Pro X Superlight (id 0xc547) including the 13
byte mouse reports.
This change adds a definition for this receiver id, and a mapping for
the recvr_type_gaming_hidpp_ls_1_3 type. With this change in place the
receiver now reports the battery status of the connected mouse over
wireless as well as exposing the HID interface needed for userspace to
perform additional configuration with libratbag/Piper.
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Document the RSPI controller on the Renesas RZ/V2N SoC. The block is
compatible with the RSPI implementation found on the RZ/V2H(P) family.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251126131619.136605-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
CQHCI_SSC1.CIT indicates to the CQE the polling period to use for
periodic SEND_QUEUE_STATUS (CMD13) polling. Some eMMCs have only one
hardware queue, and CMD13 can only query one slot at a time for data
transmission, which cannot be processed in parallel. Modifying the
CMD13 query interval can increase the query frequency and improve
random write performance.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Enabling CMDQ support can lead to random occurrences of the error log when
there are RPMB access and data flush executed:
"mmc2: Timeout waiting for hardware interrupt."
Enabling CMDQ and then issuing a DCMD as the final command before disabling
it causes the eMMC controller to auto-gate its internal clock. Chip simulation
shows this results in a state machine mismatch after CMDQ mode exit, triggering
data-timeout errors for all subsequent read and write operations.
Therefore, the auto-clock-gate function must be disabled whenever CMDQ is
enabled.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: fda1e0af7c ("mmc: sdhci-of-dwcmshc: Add command queue support for rockchip SOCs")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The current implementation calls cond_resched() for every SG entry
in __ib_umem_release(), which can increase needless overhead.
This patch introduces RESCHED_LOOP_CNT_THRESHOLD (0x1000) to limit
how often cond_resched() is called. The function now yields the CPU
once every 4096 iterations, and yield at the very first iteration
for lots of small umem case, to reduce scheduling overhead.
Fixes: d056bc45b6 ("RDMA/core: Prevent soft lockup during large user memory region cleanup")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Link: https://patch.msgid.link/20251126025147.2627-1-lirongqing@baidu.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
In some cases, this logic can result in doorbell writes being
skipped when they should not have been (at least on GEN3 HW),
so remove it. This also means that the mb() can be safely
downgraded to dma_wmb().
Fixes: 551c46edc7 ("RDMA/irdma: Add user/kernel shared libraries")
Signed-off-by: Jacob Moroni <jmoroni@google.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251125025350.180-9-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
The GEN3 hardware does not appear to support IBK_LOCAL_DMA_LKEY. Attempts
to use it will result in an AE.
Fixes: eb31dfc2b4 ("RDMA/irdma: Restrict Memory Window and CQE Timestamping to GEN3")
Signed-off-by: Jacob Moroni <jmoroni@google.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251125025350.180-8-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
The HW disables bounds checking for MRs with a length of zero, so
the driver will only allow a zero length MR if the "all_memory"
flag is set, and this flag is only set if IB_PD_UNSAFE_GLOBAL_RKEY
is set for the PD.
This means that the "get_dma_mr" method will currently fail unless
the IB_PD_UNSAFE_GLOBAL_RKEY flag is set. This has not been an issue
because the "get_dma_mr" method is only ever invoked if the device
does not support the local DMA key or if IB_PD_UNSAFE_GLOBAL_RKEY
is set, and so far, all IRDMA HW supports the local DMA lkey.
However, some new HW does not support the local DMA lkey, so the
"get_dma_mr" method needs to work without IB_PD_UNSAFE_GLOBAL_RKEY
being set.
To support HW that does not allow the local DMA lkey, the logic has
been changed to pass an explicit flag to indicate when a dma_mr is
being created so that the zero length will be allowed.
Also, the "all_memory" flag has been forced to false for normal MR
allocation since these MRs are never supposed to provide global
unsafe rkey semantics anyway; only the MR created with "get_dma_mr"
should support this.
Fixes: bb6d73d9ad ("RDMA/irdma: Prevent zero-length STAG registration")
Signed-off-by: Jacob Moroni <jmoroni@google.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251125025350.180-7-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Removes write to IRDMA_PFINT_AEQCTL register prior to destroying AEQ,
as this register does not exist in GEN3+ hardware and this kind of IRQ
configuration is no longer required.
Fixes: b800e82feb ("RDMA/irdma: Add GEN3 support for AEQ and CEQ")
Signed-off-by: Krzysztof Czurylo <krzysztof.czurylo@intel.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251125025350.180-5-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
During a refactor of the irdma GEN2 code, the kfree of the irdma_pci_f struct
in icrdma_remove(), which was originally introduced upstream as part of
commit 80f2ab46c2 ("irdma: free iwdev->rf after removing MSI-X")
was accidentally removed.
Fixes: 0c2b80cac9 ("RDMA/irdma: Refactor GEN2 auxiliary driver")
Signed-off-by: Krzysztof Czurylo <krzysztof.czurylo@intel.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251125025350.180-4-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Adds a lock around irdma_sc_ccq_arm body to prevent inter-thread data race.
Fixes data race in irdma_sc_ccq_arm() reported by KCSAN:
BUG: KCSAN: data-race in irdma_sc_ccq_arm [irdma] / irdma_sc_ccq_arm [irdma]
read to 0xffff9d51b4034220 of 8 bytes by task 255 on cpu 11:
irdma_sc_ccq_arm+0x36/0xd0 [irdma]
irdma_cqp_ce_handler+0x300/0x310 [irdma]
cqp_compl_worker+0x2a/0x40 [irdma]
process_one_work+0x402/0x7e0
worker_thread+0xb3/0x6d0
kthread+0x178/0x1a0
ret_from_fork+0x2c/0x50
write to 0xffff9d51b4034220 of 8 bytes by task 89 on cpu 3:
irdma_sc_ccq_arm+0x7e/0xd0 [irdma]
irdma_cqp_ce_handler+0x300/0x310 [irdma]
irdma_wait_event+0xd4/0x3e0 [irdma]
irdma_handle_cqp_op+0xa5/0x220 [irdma]
irdma_hw_flush_wqes+0xb1/0x300 [irdma]
irdma_flush_wqes+0x22e/0x3a0 [irdma]
irdma_cm_disconn_true+0x4c7/0x5d0 [irdma]
irdma_disconnect_worker+0x35/0x50 [irdma]
process_one_work+0x402/0x7e0
worker_thread+0xb3/0x6d0
kthread+0x178/0x1a0
ret_from_fork+0x2c/0x50
value changed: 0x0000000000024000 -> 0x0000000000034000
Fixes: 3f49d68425 ("RDMA/irdma: Implement HW Admin Queue OPs")
Signed-off-by: Krzysztof Czurylo <krzysztof.czurylo@intel.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251125025350.180-2-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Merge series from Johan Hovold <johan@kernel.org>:
This series fixes device and OF node reference leaks during probe and
a clock prepare imbalance on probe failures.
Included is a related cleanup of an error path.
The Renesas RZ/G3S features a PCIe IP that complies with the PCI Express
Base Specification 4.0 and supports speeds of up to 5 GT/s. It functions
only as a root complex, with a single-lane (x1) configuration. The
controller includes Type 1 configuration registers, as well as IP
specific registers (called AXI registers) required for various adjustments.
Hardware manual can be downloaded from the address in the "Link" section.
The following steps should be followed to access the manual:
1/ Click the "User Manual" button
2/ Click "Confirm"; this will start downloading an archive
3/ Open the downloaded archive
4/ Navigate to r01uh1014ej*-rzg3s-users-manual-hardware -> Deliverables
5/ Open the file r01uh1014ej*-rzg3s.pdf
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://www.renesas.com/en/products/rz-g3s?queryID=695cc067c2d89e3f271d43656ede4d12
Link: https://patch.msgid.link/20251119143523.977085-3-claudiu.beznea.uj@bp.renesas.com
Some platforms (e.g. SC8280XP and X1E) support more than 128 stream
matching groups. This is more than what is defined as maximum by the ARM
SMMU architecture specification. Commit 1226113473 ("iommu/arm-smmu-qcom:
Limit the SMR groups to 128") disabled use of the additional groups because
they don't exhibit the same behavior as the architecture supported ones.
It seems like this is just another quirk of the hypervisor: When running
bare-metal without the hypervisor, the additional groups appear to behave
just like all others. The boot firmware uses some of the additional groups,
so ignoring them in this situation leads to stream match conflicts whenever
we allocate a new SMR group for the same SID.
The workaround exists primarily because the bypass quirk detection fails
when using a S2CR register from the additional matching groups, so let's
perform the test with the last reliable S2CR (127) and then limit the
number of SMR groups only if we detect that we are running below the
hypervisor (because of the bypass quirk).
Fixes: 1226113473 ("iommu/arm-smmu-qcom: Limit the SMR groups to 128")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Basic tests of establishing a dmabuf and revoking it. The selftest kernel
side provides a basic small dmabuf for this testing.
Link: https://patch.msgid.link/r/9-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Finally call iopt_alloc_dmabuf_pages() if the user passed in a DMABUF
through IOMMU_IOAS_MAP_FILE. This makes the feature visible to userspace.
Link: https://patch.msgid.link/r/8-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Since dmabuf only has APIs that work on an int fd and not a struct file *,
pass the fd deeper into the call chain so we can use the dmabuf APIs as
is.
Link: https://patch.msgid.link/r/7-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Make another sub implementation of pfn_reader for DMABUF. This version
will fill the batch using the struct phys_vec recorded during the
attachment.
Link: https://patch.msgid.link/r/6-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Addresses intended for MMIO should be propagated through to the iommu with
the IOMMU_MMIO flag set.
Keep track in the batch if all the pfns are cachable or mmio and flush the
batch out of it ever needs to be changed. Switch to IOMMU_MMIO if the
batch is MMIO when mapping the iommu.
Link: https://patch.msgid.link/r/5-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
When connected to VFIO, the only DMABUF exporter that is accepted, the
move_notify callback will be made when VFIO wants to remove access to the
MMIO. This is being called revoke.
Wire up revoke to go through all the iommu_domain's that have mapped the
DMABUF and unmap them.
The locking here is unpleasant, since the existing locking scheme was
designed to come from the iopt through the area to the pages we cannot use
pages as starting point for the locking. There is no way to obtain the
domains_rwsem before obtaining the pages mutex to reliably use the
existing domains_itree.
Solve this problem by adding a new tracking structure just for DMABUF
revoke. Record a linked list of areas and domains inside the pages
mutex. Clean the entries on the list during revoke. The map/unmaps are now
all done under a pages mutex while updating the tracking linked list so
nothing can get out of sync. Only one lock is required for revoke
processing.
Link: https://patch.msgid.link/r/4-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Once a DMABUF is revoked the domain will be unmapped under the pages
mutex. Double unmapping will trigger a WARN, and mapping while revoked
will fail.
Check for revoked DMABUFs along all the map and unmap paths to resolve
this. Ensure that map/unmap is always done under the pages mutex so it is
synchronized with the revoke notifier.
If a revoke happens between allocating the iopt_pages and the population
to a domain then the population will succeed, and leave things unmapped as
though revoke had happened immediately after.
Currently there is no way to repopulate the domains. Userspace is expected
to know if it is going to do something that would trigger revoke (eg if it
is about to do a FLR) then it should go and remove the DMABUF mappings
before and put the back after. The revoke is only to protect the kernel
from mis-behaving userspace.
Link: https://patch.msgid.link/r/3-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Add IOPT_ADDRESS_DMABUF to the iopt_pages and the basic infrastructure to
create an iopt_pages from a struct dma_buf *.
DMABUF pages are not supported for accesses, and for now can only be used
with the VFIO DMABUF exporter.
The overall flow will be similar to memfd where the user can pass in a
DMABUF file descriptor to IOMMU_IOAS_MAP_FILE and create an area and
pages. Like other areas it can be copied and otherwise manipulated, though
there is little point in doing so.
There is no pinned page accounting done for DMABUF maps.
The DMABUF attachment exists so long as the dmabuf is mapped into an IOAS,
even if the IOAS is not mapped to any domains.
Link: https://patch.msgid.link/r/2-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
This function is used to establish the "private interconnect" between the
VFIO DMABUF exporter and the iommufd DMABUF importer. This is intended to
be a temporary API until the core DMABUF interface is improved to natively
support a private interconnect and revocable negotiation.
This function should only be called by iommufd when trying to map a
DMABUF. For now iommufd will only support VFIO DMABUFs.
The following improvements are needed in the DMABUF API to generically
support more exporters with iommufd/kvm type importers that cannot use the
DMA API:
1) Revoke semantics. VFIO needs to be able to prevent access to the MMIO
during FLR, and so it will use dma_buf_move_notify() to prevent
access. iommmufd does not support fault handling so it cannot
implement the full move_notify. Instead if revoke is negotiated the
exporter promises not to use move_notify() unless the importer can
experiance failures. iommufd will unmap the dmabuf from the iommu page
tables while it is revoked.
2) Private interconnect negotiation. iommufd will only be able to map
a "private interconnect" that provides a phys_addr_t and a
struct p2pdma_provider * to describe the memory. It cannot use a DMA
mapped scatterlist since it is directly calling iommu_map().
3) NULL device during dma_buf_dynamic_attach(). Since iommufd doesn't use
the DMA API it doesn't have a DMAable struct device to pass here.
Link: https://patch.msgid.link/r/1-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Acked-by: Alex Williamson <alex@shazbot.org>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Since increase_top() does it's own READ_ONCE() on top_of_table, the
caller's prior READ_ONCE() could be inconsistent and the first time
through the loop we may actually already have the right level if two
threads are racing map.
In this case new_level will be left uninitialized.
Further all the exits from the loop have to either commit to the new top
or free any memory allocated so the early return must be a goto err_free.
Make it so the only break from the loop always sets new_level to the right
value and all other exits go to err_free. Use pts.level (the pts
represents the top we are stacking) within the loop instead of new_level.
Fixes: dcd6a011a8 ("iommupt: Add map_pages op")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/aRwgNW9PiW2j-Qwo@stanley.mountain
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The return type of __modify_irte_ga() is int, but modify_irte_ga()
treats it as a bool. Casting the int to bool discards the error code.
To fix the issue, change the type of ret to int in modify_irte_ga().
Fixes: 57cdb720ea ("iommu/amd: Do not flush IRTE when only updating isRun and destination fields")
Cc: stable@vger.kernel.org
Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Having the host bridge allocation inside pci_host_common_init() results
in a lot of complexity in the pcie-apple driver (the only direct user
of this function outside of core PCI code).
It forces the allocation of driver-specific tracking structures outside
of the bridge allocation, which in turn requires it to use inefficient
data structures to match the bridge and the private structure as needed.
Instead, let the bridge structure be passed to pci_host_common_init(),
allowing the driver to allocate it together with the private data,
as it is usually intended. The driver can then retrieve the bridge
via the owning device attached to the PCI config window structure.
This allows the pcie-apple driver to be significantly simplified.
Both core and driver code are changed in one go to avoid going via
a transitional interface.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Radu Rendec <rrendec@redhat.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Wilczyński <kwilczynski@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Link: https://lore.kernel.org/r/86jyzms036.wl-maz@kernel.org
Link: https://patch.msgid.link/20251125102726.865617-1-maz@kernel.org
Use jpb@kernel.org as my main address.
Signed-off-by: Jean-Philippe Brucker <jpb@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-15-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-14-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-13-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-12-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251124002105.25429-11-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Andy Shevchenko <andy@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-10-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-9-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-8-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-7-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Andy Shevchenko <andy@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-6-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use #ifdef guards.
This has the advantage of always compiling these functions in,
independently of any Kconfig option. Thanks to that, bugs and other
regressions are subsequently easier to catch.
The pl061_context_save_regs structure is always embedded into struct
pl061 to simplify code, so this brings a tiny 8 bytes memory overhead
for !CONFIG_PM_SLEEP.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-5-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use #ifdef guards.
This has the advantage of always compiling these functions in,
independently of any Kconfig option. Thanks to that, bugs and other
regressions are subsequently easier to catch.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-4-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use #ifdef guards.
This has the advantage of always compiling these functions in,
independently of any Kconfig option. Thanks to that, bugs and other
regressions are subsequently easier to catch.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Doug Berger <opendmb@gmail.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251124002105.25429-3-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use #ifdef guards.
This has the advantage of always compiling these functions in,
independently of any Kconfig option. Thanks to that, bugs and other
regressions are subsequently easier to catch.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://lore.kernel.org/r/20251124002105.25429-2-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
* Replace min_t() by min() to avoid cutting upper bits and do type checking
gpiolib: acpi: use min() instead of min_t()
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEqaflIX74DDDzMJJtb7wzTHR8rCgFAmkliTIACgkQb7wzTHR8
rCgseg/9GLm1WQnkbfIaJ1EdjQF3nqpsxvsmrh+aS/eqzV6TSSKGpqBFWKXBJ6oB
DZhBk8gGFsptdtgWu+4A2g4wzziGG3syVKmu0FkAdtG9Aep94cY1eaf+KjP913FV
XYrzYFtwSDOABS7QoA/VogGv7+Ceww8WGfOmyzuEvAf0b3zeHNOEjEB8WH56O3j2
0doJ+yfFrIJjKR3Cxld4S1u0f4Aezi5nF21Bec1aiTH4BOuJdPBfdpE7Gjt2/Hn2
TAliHTfGeqJAcdTHt7GJYYy4EAXuzyBj6XKdsvphYck62ToRCgqKLG3dbSyOmiD7
YzDC/viyBkRpsKh0zKIzFtSAfoJpz+3EfGKktHyULCGI0y3fPHzFZOcGZb6fIHo2
ZjMuuhVRieckEjGK8MJxp97qa5X3oEs7yEQdGanTg/t8v3kYTk/hX0BCwL6p7WXe
pzafkqDclYwa5vUbLQhFabxCTCXlpC00UutEOr7trd9PUBrm4asU0uEd0xralMU/
XLVuJb0fW/76+TKUAG8RWdJDMxVImu6UANFkaWgxV8Cck+TEdU/4pSTbktV78Fpn
W6IofRcuhc6ODw8R4dZHVNZLaNDNvHH+R/0sk/ZfpdfHYFzkrYhr/aIgHP5ldrh0
wKvyL0KUHwMdjvIApEAlPjxe+P3PcQrcq31lm7qApsj0j8qzMKA=
=JZZc
-----END PGP SIGNATURE-----
Merge tag 'intel-gpio-v6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-next
intel-gpio for v6.19-1
* Replace min_t() by min() to avoid cutting upper bits and do type checking
gpiolib: acpi: use min() instead of min_t()
Merge the mmc fixes for v6.18-rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.19.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add a missing struct short description and a missing leading " *" to
lp855x.h to avoid kernel-doc warnings:
Warning: include/linux/platform_data/lp855x.h:126 missing initial short
description on line:
* struct lp855x_platform_data
Warning: include/linux/platform_data/lp855x.h:131 bad line:
Only valid when mode is PWM_BASED.
Fixes: 7be865ab86 ("backlight: new backlight driver for LP855x devices")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20251111060916.1995920-1-rdunlap@infradead.org
Signed-off-by: Lee Jones <lee@kernel.org>
Add Awinic AW99706 backlight binding documentation.
Signed-off-by: Junjie Cao <caojunjie650@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251109032240.3422503-2-caojunjie650@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for Awinic AW99706 backlight, which can be found in
tablet and notebook backlight, one case is the Lenovo Legion Y700
Gen4. This driver refers to the official datasheets and android
driver, they can be found in [1].
[1] https://www.awinic.com/en/productDetail/AW99706QNR
Signed-off-by: Junjie Cao <caojunjie650@gmail.com>
Tested-by: Pengyu Luo <mitltlatltl@gmail.com>
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20251109032240.3422503-3-caojunjie650@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
LED Backlight is a consumer of one or multiple LED class devices, but
devlink is currently unable to create correct supplier-producer links when
the supplier is a class device. It creates instead a link where the
supplier is the parent of the expected device.
One consequence is that removal order is not correctly enforced.
Issues happen for example with the following sections in a device tree
overlay:
// An LED driver chip
pca9632@62 {
compatible = "nxp,pca9632";
reg = <0x62>;
// ...
addon_led_pwm: led-pwm@3 {
reg = <3>;
label = "addon:led:pwm";
};
};
backlight-addon {
compatible = "led-backlight";
leds = <&addon_led_pwm>;
brightness-levels = <255>;
default-brightness-level = <255>;
};
In this example, the devlink should be created between the backlight-addon
(consumer) and the pca9632@62 (supplier). Instead it is created between the
backlight-addon (consumer) and the parent of the pca9632@62, which is
typically the I2C bus adapter.
On removal of the above overlay, the LED driver can be removed before the
backlight device, resulting in:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
...
Call trace:
led_put+0xe0/0x140
devm_led_release+0x6c/0x98
Another way to reproduce the bug without any device tree overlays is
unbinding the LED class device (pca9632@62) before unbinding the consumer
(backlight-addon):
echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind
echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind
Fix by adding a devlink between the consuming led-backlight device and the
supplying LED device, as other drivers and subsystems do as well.
Fixes: ae232e45ac ("backlight: add led-backlight driver")
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Link: https://patch.msgid.link/20250519-led-backlight-add-devlink-to-supplier-class-device-v6-1-845224aeb2ce@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
According to the hardware programming guide, the clock frequency must
remain below 52MHz during the transition to HS400 mode.
However,in the current implementation, the timing is set to HS400 (a
DDR mode) before adjusting the clock. This causes the clock to double
prematurely to 104MHz during the transition phase, violating the
specification and potentially resulting in CRC errors or CMD timeouts.
This change ensures that clock doubling is avoided during intermediate
transitions and is applied only when the card requires a 200MHz clock
for HS400 operation.
Signed-off-by: Sarthak Garg <sarthak.garg@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn offered to help with the Synposys Designware MMC/SD/SDIO drivers,
let's add him as a co-maintainer.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com> > Signed-off-by: Ulf
When I added command queue engine (CQE) support for the Rockchip eMMC
controller, I missed that RK3576 has a separate platform data struct.
While things are working fine on RK3588 (I tested the ROCK 5B) and
the suspend issue is fixed on the RK3576 (I tested the Sige5), this
results in stability issues. By also adding the necessary hooks for
the RK3576 platform the following problems can be avoided:
[ 15.606895] mmc0: running CQE recovery
[ 15.616189] mmc0: running CQE recovery
[...]
[ 25.911484] mmc0: running CQE recovery
[ 25.926305] mmc0: running CQE recovery
[ 25.927468] mmc0: running CQE recovery
[...]
[ 26.255719] mmc0: running CQE recovery
[ 26.257162] ------------[ cut here ]------------
[ 26.257581] mmc0: cqhci: spurious TCN for tag 31
[ 26.258034] WARNING: CPU: 0 PID: 0 at drivers/mmc/host/cqhci-core.c:796 cqhci_irq+0x440/0x68c
[ 26.263786] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-rc6-gd984ebbf0d15 #1 PREEMPT
[ 26.264561] Hardware name: ArmSoM Sige5 (DT)
[...]
[ 26.272748] Call trace:
[ 26.272964] cqhci_irq+0x440/0x68c (P)
[ 26.273296] dwcmshc_cqe_irq_handler+0x54/0x88
[ 26.273689] sdhci_irq+0xbc/0x1200
[ 26.273991] __handle_irq_event_percpu+0x54/0x1d0
[...]
Note that the above problems do not necessarily happen with every boot.
Reported-by: Adrian Hunter <adrian.hunter@intel.com>
Closes: https://lore.kernel.org/linux-rockchip/01949bc9-4873-498b-ac7d-f008393ccc4c@intel.com/
Fixes: fda1e0af7c ("mmc: sdhci-of-dwcmshc: Add command queue support for rockchip SOCs")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
Base Specification 4.0. It is designed for root complex applications and
features a single-lane (x1) implementation. Add binding documentation for
it.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251119143523.977085-2-claudiu.beznea.uj@bp.renesas.com
Add missing temperature and fan sensors to Pro WS TRX50-SAGE WIFI
Also:
- Format VRM names to match the BIOS
- Fix swapped VRM_E and VRM_W entries
Signed-off-by: 小太 <nospam@kota.moe>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20251125040140.277756-1-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
According to Dan Carpenter, smatch detects issue with size parameter given
to pci_rebar_size_supported():
drivers/pci/rebar.c:142 pci_rebar_size_supported()
error: undefined (user controlled) shift '(((1))) << size'
The problem is this call tree, which uses the 'size' from the user to shift
in BIT() without validating it:
__resource_resize_store # takes 'buf' from user sysfs write
kstrtoul(buf, 0, &size) # converts to unsigned long
pci_resize_resource # truncates to int
pci_rebar_size_supported # BIT(size) without validation
There could be similar problems also with pci_resize_resource() parameter
values coming from drivers.
Add 'size' validation to pci_rebar_size_supported().
There seems to be no SZ_128T prior to this so add one to be able to specify
the largest size supported by the kernel (PCIe r7.0 spec already defines
sizes even beyond 128TB but kernel does not yet support them).
The issue looks older than the introduction of pci_rebar_size_supported()
by bb1fabd0d9 ("PCI: Add pci_rebar_size_supported() helper").
It would be also nice to convert 'size' unsigned too everywhere, maybe even
u8 but that is left as further work.
Fixes: 8bb705e3e7 ("PCI: Add pci_resize_resource() for resizing BARs")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/aSA1WiRG3RuhqZMY@stanley.mountain/
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[bhelgaas: commit log, add report URL]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251124153740.2995-1-ilpo.jarvinen@linux.intel.com
After recovering from a PCI error through reset, affected devices are in
D0_uninitialized state and need to be brought into D0_active state by
re-initializing their Config Space registers (PCIe r7.0 sec 5.3.1.1).
To facilitate that, the PCI core provides pci_restore_state() and
pci_save_state() helpers. Document rules governing their usage.
As Bjorn notes, so far no file in "Documentation/ includes anything about
the idea of a driver using pci_save_state() to capture the state it wants
to restore after an error", even though it is a common pattern in drivers.
So that's obviously a gap that should be closed.
Reported-by: Bjorn Helgaas <helgaas@kernel.org>
Closes: https://lore.kernel.org/r/20251113161556.GA2284238@bhelgaas/
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Link: https://patch.msgid.link/077596ba70202be0e43fdad3bb9b93d356cbe4ec.1763746079.git.lukas@wunner.de
In 2009, commit c82f63e411 ("PCI: check saved state before restore")
changed the behavior of pci_restore_state() such that it became necessary
to call pci_save_state() afterwards, lest recovery from subsequent PCI
errors fails.
The commit has just been reverted and so all the pci_save_state() after
pci_restore_state() calls that have accumulated in the tree are now
superfluous. Drop them.
Two drivers chose a different approach to achieve the same result:
drivers/scsi/ipr.c and drivers/net/ethernet/intel/e1000e/netdev.c set the
pci_dev's "state_saved" flag to true before calling pci_restore_state().
Drop this as well.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> # qat
Link: https://patch.msgid.link/c2b28cc4defa1b743cf1dedee23c455be98b397a.1760274044.git.lukas@wunner.de
When the PCI core gained power management support in 2002, it introduced
pci_save_state() and pci_restore_state() helpers to restore Config Space
after a D3hot or D3cold transition, which implies a Soft or Fundamental
Reset (PCIe r7.0 sec 5.8):
https://git.kernel.org/tglx/history/c/a5287abe398b
In 2006, EEH and AER were introduced to recover from errors by performing
a reset. Because errors can occur at any time, drivers began calling
pci_save_state() on probe to ensure recoverability.
In 2009, recoverability was foiled by commit c82f63e411 ("PCI: check
saved state before restore"): It amended pci_restore_state() to bail out
if the "state_saved" flag has been cleared. The flag is cleared by
pci_restore_state() itself, hence a saved state is now allowed to be
restored only once and is then invalidated. That doesn't seem to make
sense because the saved state should be good enough to be reused.
Soon after, drivers began to work around this behavior by calling
pci_save_state() immediately after pci_restore_state(), see e.g. commit
b94f2d775a ("igb: call pci_save_state after pci_restore_state").
Hilariously, two drivers even set the "saved_state" flag to true before
invoking pci_restore_state(), see ipr_reset_restore_cfg_space() and
e1000_io_slot_reset().
Despite these workarounds, recoverability at all times is not guaranteed:
E.g. when a PCIe port goes through a runtime suspend and resume cycle,
the "saved_state" flag is cleared by:
pci_pm_runtime_resume()
pci_pm_default_resume_early()
pci_restore_state()
... and hence on a subsequent AER event, the port's Config Space cannot be
restored. Riana reports a recovery failure of a GPU-integrated PCIe
switch and has root-caused it to the behavior of pci_restore_state().
Another workaround would be necessary, namely calling pci_save_state() in
pcie_port_device_runtime_resume().
The motivation of commit c82f63e411 was to prevent restoring state if
pci_save_state() hasn't been called before. But that can be achieved by
saving state already on device addition, after Config Space has been
initialized. A desirable side effect is that devices become recoverable
even if no driver gets bound. This renders the commit unnecessary, so
revert it.
Reported-by: Riana Tauro <riana.tauro@intel.com> # off-list
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Riana Tauro <riana.tauro@intel.com>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Link: https://patch.msgid.link/9e34ce61c5404e99ffdd29205122c6fb334b38aa.1763483367.git.lukas@wunner.de
The state_saved flag tells the PCI core whether a driver assumes
responsibility to save Config Space and put the device into a low power
state on suspend.
The flag is currently initialized to false on enumeration, even though it
already is false (because struct pci_dev is zeroed by kzalloc()) and even
though it is set to false before commencing the suspend sequence (the only
code path where it's relevant).
The flag is also set to false in pci_pm_thaw(), i.e. on resume, when it's
no longer relevant.
Drop these two superfluous flag assignments for simplicity.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Link: https://patch.msgid.link/fd167945bd7852e1ca08cd4b202130659eea2c2f.1763483367.git.lukas@wunner.de
When a PCI device is suspended, it is normally the PCI core's job to save
Config Space and put the device into a low power state. However drivers
are allowed to assume these responsibilities. When they do, the PCI core
can tell by looking at the state_saved flag in struct pci_dev: The flag
is cleared before commencing the suspend sequence and it is set when
pci_save_state() is called. If the PCI core finds the flag set late in
the suspend sequence, it refrains from calling pci_save_state() itself.
But there are two corner cases where the PCI core neglects to clear the
flag before commencing the suspend sequence:
* If a driver has legacy PCI PM callbacks, pci_legacy_suspend() neglects
to clear the flag. The (stale) flag is subsequently queried by
pci_legacy_suspend() itself and pci_legacy_suspend_late().
* If a device has no driver or its driver has no PCI PM callbacks,
pci_pm_freeze() neglects to clear the flag. The (stale) flag is
subsequently queried by pci_pm_freeze_noirq().
The flag may be set prior to suspend if the device went through error
recovery: Drivers commonly invoke pci_restore_state() + pci_save_state()
to restore Config Space after reset.
The flag may also be set if drivers call pci_save_state() on probe to
allow for recovery from subsequent errors.
The result is that pci_legacy_suspend_late() and pci_pm_freeze_noirq()
don't call pci_save_state() and so the state that will be restored on
resume is the one recorded on last error recovery or on probe, not the one
that the device had on suspend. If the two states happen to be identical,
there's no problem.
Reinstate clearing the flag in pci_legacy_suspend() and pci_pm_freeze().
The two functions used to do that until commit 4b77b0a2ba ("PCI: Clear
saved_state after the state has been restored") deemed it unnecessary
because it assumed that it's sufficient to clear the flag on resume in
pci_restore_state(). The commit seemingly did not take into account that
pci_save_state() and pci_restore_state() are not only used by power
management code, but also for error recovery.
Devices without driver or whose driver has no PCI PM callbacks may be in
runtime suspend when pci_pm_freeze() is called. Their state has already
been saved, so don't clear the flag to skip a pointless pci_save_state()
in pci_pm_freeze_noirq().
None of the drivers with legacy PCI PM callbacks seem to use runtime PM,
so clear the flag unconditionally in their case.
Fixes: 4b77b0a2ba ("PCI: Clear saved_state after the state has been restored")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Cc: stable@vger.kernel.org # v2.6.32+
Link: https://patch.msgid.link/094f2aad64418710daf0940112abe5a0afdc6bce.1763483367.git.lukas@wunner.de
L1 PM Substates for RC mode require support in the dw-rockchip driver
including proper handling of the CLKREQ# sideband signal. It is mostly
handled by hardware, but software still needs to set the clkreq fields
in the PCIE_CLIENT_POWER_CON register to match the hardware implementation.
For more details, see section '18.6.6.4 L1 Substate' in the RK3568 TRM 1.1
Part 2, or section '11.6.6.4 L1 Substate' in the RK3588 TRM 1.0 Part2.
[bhelgaas: set pci->l1ss_support so DWC core preserves L1SS Capability bits;
drop corresponding code here, include updates from
https://lore.kernel.org/r/aRRG8wv13HxOCqgA@ryzen]
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1761187883-150120-1-git-send-email-shawn.lin@rock-chips.com
Link: https://patch.msgid.link/20251118214312.2598220-4-helgaas@kernel.org
The DWC core clears the L1 Substates Supported bits unless the driver sets
the "dw_pcie.l1ss_support" flag.
The tegra194 init_host_aspm() sets "dw_pcie.l1ss_support" if the platform
has the "supports-clkreq" DT property. If "supports-clkreq" is absent,
"dw_pcie.l1ss_support" is not set, and the DWC core will clear the L1
Substates Supported bits.
The tegra194 code to clear the L1 Substates Supported bits is unnecessary,
so remove it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251118214312.2598220-3-helgaas@kernel.org
L1 PM Substates require the CLKREQ# signal and may also require
device-specific support. If CLKREQ# is not supported or driver support is
lacking, enabling L1.1 or L1.2 may cause errors when accessing devices,
e.g.,
nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
If the kernel is built with CONFIG_PCIEASPM_POWER_SUPERSAVE=y or users
enable L1.x via sysfs, users may trip over these errors even if L1
Substates haven't been enabled by firmware or the driver.
To prevent such errors, disable advertising the L1 PM Substates unless the
driver sets "dw_pcie.l1ss_support" to indicate that it knows CLKREQ# is
present and any device-specific configuration has been done.
Set "dw_pcie.l1ss_support" in tegra194 (if DT includes the
"supports-clkreq' property) and qcom (for cfg_2_7_0, cfg_1_9_0, cfg_1_34_0,
and cfg_sc8280xp controllers) so they can continue to use L1 Substates.
Based on Niklas's patch:
https://patch.msgid.link/20251017163252.598812-2-cassel@kernel.org
[bhelgaas: drop hiding for endpoints]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251118214312.2598220-2-helgaas@kernel.org
As per DesignWare Cores PCI Express Controller Databook, section 5.50,
SII: Debug Signals, cxpl_debug_info[63:0]:
[5:0] smlh_ltssm_state: LTSSM current state. Encoding is same as the
dedicated smlh_ltssm_state output.
The mask should be 6 bits, from 0 to 5. Hence, fix the mask definition.
Fixes: 23fe5bd4be ("PCI: keystone: Cleanup ks_pcie_link_up()")
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
[mani: reworded description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1763122140-203068-1-git-send-email-shawn.lin@rock-chips.com
TC9563 is a PCIe switch that has one upstream and three downstream ports.
One of the downstream ports is connected to an integrated ethernet MAC
endpoint. The other two downstream ports are available to connect to
external devices. One Host can connect to TC9563 by upstream port. The
TC9563 switch needs to be configured after powering on and before the PCIe
link is up.
The PCIe controller driver already enables link training at the host side
even before this driver probe happens. Due to this, when driver enables
power to the switch, it participates in link training and the PCIe link may
come up before configuring the switch through I2C. Once the link is up the
configuration done through I2C will not have any effect. To prevent the
host from participating in link training, disable link training on the host
side to ensure the link does not come up before the switch is configured
via I2C.
Based on DT property and type of the port, TC9563 is configured through
I2C.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[bhelgaas: squash fixes from
https://lore.kernel.org/r/20251120065116.13647-2-mani@kernel.orghttps://lore.kernel.org/r/20251120065116.13647-3-mani@kernel.org]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251101-tc9563-v9-6-de3429f7787a@oss.qualcomm.com
In this code:
used_buses = max_t(unsigned int, available_buses,
pci_hotplug_bus_size - 1);
max_t() casts the 'unsigned long' pci_hotplug_bus_size (either 32 or 64
bits) to 'unsigned int' (32 bits) result type, so there's a potential of
discarding significant bits.
Instead, use max(a, b), which casts 'unsigned int' to 'unsigned long' and
cannot discard significant bits.
In this case, pci_hotplug_bus_size is constrained to <= 0xff by pci_setup()
so this doesn't fix a bug, but it makes static analysis easier.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251119224140.8616-26-david.laight.linux@gmail.com
The macro FAN_FROM_REG evaluates its arguments multiple times. When used
with shared driver data, this leads to Time-of-Check to Time-of-Use
(TOCTOU) race conditions, potentially causing divide-by-zero errors.
Convert the macro to a static function to ensure arguments are evaluated
only once.
Additionally, in fan_div_store, move the reading of the old register
value and the calculation of the minimum limit inside the update lock.
This ensures that the read-modify-write sequence operates on consistent
data, preventing race conditions during fan divider updates.
Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://lore.kernel.org/r/20251124165900.4713-1-hanguidong02@gmail.com
[groeck: Dropped unnecessary line split]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The functions fan1_input_show and fan1_target_show check shared data for
zero before using it as a divisor. These accesses are currently
lockless. If the data changes to zero between the check and the
division, it causes a divide-by-zero error.
Explicitly acquire the update lock around these checks and calculations
to ensure the data remains stable, preventing Time-of-Check to
Time-of-Use (TOCTOU) race conditions.
Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://lore.kernel.org/r/20251124165508.4667-1-hanguidong02@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In arm_smmu_alloc_cd_tables(), the error check following the
dma_alloc_coherent() for cd_table->l2.l1tab incorrectly tests
cd_table->l2.l2ptrs.
This means an allocation failure for l1tab goes undetected, causing
the function to return 0 (success) erroneously.
Correct the check to test cd_table->l2.l1tab.
Fixes: e3b1be2e73 ("iommu/arm-smmu-v3: Reorganize struct arm_smmu_ctx_desc_cfg")
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Ryan Huang <tzukui@google.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Will Deacon <will@kernel.org>
Some IOMMUs on some platforms (there doesn't seem to be a good denominator
for this) require the presence of a third clock, specifically relating
to the instance's Translation Buffer Unit (TBU).
Stephan Gerhold noted [1] that according to Qualcomm Snapdragon 410E
Processor (APQ8016E) Technical Reference Manual, SMMU chapter, section
"8.8.3.1.2 Clock gating", which reads:
For APPS TCU/TBU (TBU to TCU interface is asynchronous)
Software should turn ON clock to APPS TCU
- During APPS TCU register programming sequence
For GPU TCU/TBU (TBU to TCU interface is synchronous)
Software should turn ON clock to GPU TBU
- During GPU TLB invalidation sequence <=====================
Software should turn ON clock to GPU TCU
- During GPU TCU register programming sequence
- While GPU master clock is Active
The clock should be turned on at least during TLB invalidation on the
GPU SMMU instance. This is corroborated by Commit 5bc1cf1466
("iommu/qcom: add optional 'tbu' clock for TLB invalidate").
This is also not to be confused with qcom,sdm845-tbu, which is a
description of a debug interface, absent on the generation of hardware
that this binding describes.
Allow this clock.
[1] https://lore.kernel.org/linux-arm-msm/aPX_cKtial56AgvU@linaro.org/
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
If the device tree is messed up, then potentially the "protocol" string
could potentially be uninitialized. The property is supposed to default
to "motorola" so if the of_property_read_string() function returns
-EINVAL then default to "motorola".
Fixes: 059f545832 ("spi: add support for microchip "soft" spi controller")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Link: https://patch.msgid.link/aSQPkfkiJ0w-FJMW@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
Compared to the previously supported RZ/V2H, the Renesas RZ/T2H
(R9A09G077) and RZ/N2H (R9A09G087) SoCs have a smaller FIFO, no resets,
and only two clocks: PCLKSPIn and PCLK. PCLKSPIn, being the clock from
which the SPI transfer clock is generated, is the equivalent of the TCLK
clock from RZ/V2H. They also support generating the SPI transfer clock
from PCLK.
PCLKSPIn supports multiple dividers, generating multiple possible
frequencies from its parent. To handle this, do the following changes.
Use the minimum frequency of SPI clock to calculate the SPI controller's
min_speed_hz, and the maximum frequency to calculate max_speed_hz.
Add a new function, rzv2h_rspi_find_rate_variable(), which is used for
the .find_tclk_rate() callback, and which supports handling clocks with
a variable rate, with the following overall logic.
Iterate through all possible BRDV values.
For each BRDV, calculate two different SPRs, one for the clock's minimum
frequency, and one for the maxmimum, and iterate through each SPR
between them.
If the minimum SPR is higher than the upper SPR limit, the minimum rate
is too high to achieve the requested SPI frequency, skip to the next
BRDV.
For each SPR, calculate a rate and let the clock framework round it to
the closest supported rate of the clock.
The rate and SPR that generate a transfer frequency closest to the
requested SPI transfer frequency will be picked.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-12-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs have four SPI
peripherals.
Compared to the previously supported RZ/V2H, these SoCs have a smaller
FIFO, no resets, and only two clocks: PCLKSPIn and PCLK. PCLKSPIn,
being the clock from which the SPI transfer clock is generated, is the
equivalent of the TCLK from V2H.
Document them, and use RZ/T2H as a fallback for RZ/N2H as the SPIs are
entirely compatible.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251119161434.595677-11-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for loopback mode for debugging purposes, allowing us to
test the SPI controller at the maximum SPI transfer clock without being
limited by external wiring.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-10-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs have a more
complicated clocking setup for the SPI transfer clock than RZ/V2H, as
the clock from which it is generated supports multiple dividers.
To prepare for adding support for these SoCs, do the following changes.
Use the minimum frequency of SPI clock to calculate the SPI
controller's min_speed_hz, and the maximum frequency to calculate
max_speed_hz.
Apply the clock rate found by the .find_tclk_rate() to the found clock.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-9-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs support
generating the SPI transfer clock from PCLK, with the quirk that SPR 0
is not supported, causing the highest achievable SPI transfer frequency
to be 31.25MHz.
Add support for generating the SPI transfer clock from PCLK.
Renesas RZ/V2H (R9A09G057) also has the BPEN bit used to enable this
option in the datasheet, but it is not explicitly documented and there's
no details about its limitations as there are on RZ/T2H.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-8-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs have a more
complicated clocking setup for the SPI transfer clock than RZ/V2H, as
the clock from which it is generated supports multiple dividers.
To prepare for adding support for these SoCs, split out the logic for
finding the SPR and BRDV for a fixed clock into
rzv2h_rspi_find_rate_fixed(), and add and use a .find_tclk_rate()
callback into the chip-specific structure.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-7-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs have a more
complicated algorithm for calculating the optimal SPI transfer frequency
compared to RZ/V2H, as the clock from which the SPI frequency is
generated supports multiple dividers.
Cache the requested transfer frequency and skip calling
rzv2h_rspi_setup_clock() if it matches the last used one to prepare for
adding support for variable clock frequency handling.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-6-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In preparation for caching the last requested transfer frequency, move
register writes outside of rzv2h_rspi_setup_clock().
The transfer list is iterated to determine the speed of the transfer
and the bits per word.
The speed of the transfer is used to compute SPR and BRDV inside
rzv2h_rspi_setup_clock().
BRDV and SPB are stored in the SPCMD register.
Move the transfer iteration earlier, move the SPR and BRDV writing out
of rzv2h_rspi_setup_clock(), consolidate writing BRDV and SPB into the
initial write to the SPCMD register.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-5-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs have
different clocks compared to RZ/V2H. Set the number of clocks and the
name of the transfer clock in the chip-specific structure to prepare for
adding support for them.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-4-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs have a
different FIFO size compared to RZ/V2H. Add a chip-specific structure,
and set the FIFO size inside it, to prepare for adding support for them.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-3-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs don't have
reset lines for the SPI peripheral, make them optional to prepare for
adding support for them.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Link: https://patch.msgid.link/20251119161434.595677-2-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge the pmdomain fixes for v6.18-rc[n] into the next branch, to allow
them to get tested together with the new changes that are targeted for
v6.19.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add a check for 1600G_8X link speed when querying PTYS and report it
back correctly when needed.
While at it, adjust mlx5 function which maps the speed rate from IB
spec values to internal driver values to be able to handle speeds
up to 1600Gbps.
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Link: https://patch.msgid.link/20251120-speed-8-v1-2-e6a7efef8cb8@nvidia.com
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Add the new rates as defined in the Infiniband spec for XDR and 8x
link width support.
Furthermore, modify the utility conversion methods accordingly.
Reference: IB Spec Release 1.8
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Link: https://patch.msgid.link/20251120-speed-8-v1-1-e6a7efef8cb8@nvidia.com
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Enabling 5-level paging (LA57) increases TASK_SIZE on x86_64 from 2^47
to 2^56. This affects implicit ODP, which uses TASK_SIZE to calculate
the number of IMR KSM entries.
As a result, the number of entries and the memory usage for KSM mkeys
increase drastically:
- With 2^47 TASK_SIZE: 0x20000 entries (~2MB)
- With 2^56 TASK_SIZE: 0x4000000 entries (~1GB)
This issue could happen previously on systems with LA57 manually
enabled, but now commit 7212b58d6d ("x86/mm/64: Make 5-level paging
support unconditional") enables LA57 by default on all supported
systems. This makes the issue impact widespread.
To mitigate this, increase the size each MTT entry maps from 1GB to 16GB
when 5-level paging is enabled. This reduces the number of KSM entries
and lowers the memory usage on LA57 systems from 1GB to 64MB per IMR.
As now 'mlx5_imr_mtt_size' is larger than 32 bits, we move to use u64
instead of int as part of populate_klm() to prevent overflow of the
'step' variable.
In addition, as populate_klm() actually handles KSM and not KLM, as it's
used only by implicit ODP, we renamed its signature and the internal
structures accordingly while dropping the byte_count handling which is
not relevant in KSM. The page size in KSM is fixed for all the entries
and come from the log_page_size of the mkey.
Note:
On platforms where the calculated value for 'mlx5_imr_ksm_page_shift' is
higher than the max firmware cap to be changed over UMR, or that the
calculated value for 'log_va_pages' is higher than what we may expect,
the implicit ODP cap will be simply turned off.
Co-developed-by: Or Har-Toov <ohartoov@nvidia.com>
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20251120-reduce-ksm-v1-1-6864bfc814dc@kernel.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
DMA MR doesn't use the unified MR model. So the lkey passed
on to the reg_mr command to FW should contain the correct
lkey. Driver is incorrectly over writing the lkey with pdid
and firmware commands fails due to this.
Avoid passing the wrong key for cases where the unified MR
registration is not used.
Fixes: f786eebbbe ("RDMA/bnxt_re: Avoid an extra hwrm per MR creation")
Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
Link: https://patch.msgid.link/1763624215-10382-2-git-send-email-selvin.xavier@broadcom.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Inline size supported by the device is based on the number
of SGEs supported by the adapter. Change the inline
size calculation based on that.
Fixes: de1d364c38 ("RDMA/bnxt_re: Add support for Variable WQE in Genp7 adapters")
Reviewed-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
Link: https://patch.msgid.link/1763624215-10382-1-git-send-email-selvin.xavier@broadcom.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
The link state of bond depends on the upper device. Adapt current
link state querying flow and ib_event dispatching flow to report
correct link state of bond.
Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
Link: https://patch.msgid.link/20251112093510.3696363-8-huangjunxian6@hisilicon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
When conditions are met, schedule a delayed work in bond event handler
to perform bonding operation according to the bond state. In the case
of changing slave number or link state, re-set the netdev for the bond
ibdev after the modification is complete, since these two operations
may not call hns_roce_set_bond_netdev() in hns_roce_init().
The delayed work will be paused when there is a driver reset or exit
to avoid concurrency.
Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
Link: https://patch.msgid.link/20251112093510.3696363-7-huangjunxian6@hisilicon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Implement hns_roce_slave_init() and hns_roce_slave_uninit() for device
init/uninit in bonding cases. The former is used to initialize a slave
ibdev (when the slave is unlinked from a bond) or a bond ibdev, while
the latter does the opposite. Most of the process is the same as
regular device init/uninit, while some bonding‑specific steps below are
also added.
In bond device init flow, choose one slave to re-initialize as the
main_hr_dev of the bond, and it will be the only device presented for
multiple slaves. During registration, set and active netdev to the
ibdev based on the link state of the slaves. When this main_hr_dev
slave is being unlinked while the bond is still valid, choose a new
slave from the rest and initialize it as the new bond device.
In uninit flow, add a bond cleanup process, restore all the other
slaves and clean up bond resource. This is only for the case where
the port of main_hr_dev is directly removed without unlinking it
from bond.
Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
Link: https://patch.msgid.link/20251112093510.3696363-6-huangjunxian6@hisilicon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Register netdev notifier for two bonding events NETDEV_CHANGEUPPER
and NETDEV_CHANGELOWERSTATE.
In NETDEV_CHANGEUPPER event handler, check some rules about the HW
constraints when trying to link a new slave to the masteri, and
store some bonding information from the notifier. In unlinking case,
simply check the number of the rest slaves to decide whether the
bond is still supported.
In NETDEV_CHANGELOWERSTATE event handler, not much is done. It
simply sets the bond state when the bond is ready, which will be
used later.
Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
Link: https://patch.msgid.link/20251112093510.3696363-4-huangjunxian6@hisilicon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Allocate bond_grp resources for each card when the first device in
this card is registered. Block the initialization of VF when its PF
is a bonded slave, as VF is not supported in this case due to HW
constraints.
Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
Link: https://patch.msgid.link/20251112093510.3696363-3-huangjunxian6@hisilicon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Register and get the basic required resources from bnge driver.
Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Link: https://patch.msgid.link/20251117171136.128193-4-siva.kallam@broadcom.com
Reviewed-by: Usman Ansari <usman.ansari@broadcom.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Add basic Auxiliary interface to the driver which supports
the BCM5770X NIC family.
Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Link: https://patch.msgid.link/20251117171136.128193-3-siva.kallam@broadcom.com
Reviewed-by: Usman Ansari <usman.ansari@broadcom.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Extends device tree support to include the AST2700 chip variant by
adding its compatible string to the device match table.
The AST2700 PWM/TACH hardware is compatible with the existing driver
implementation used for AST2600.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20251120-upstream_pwm_tach-v3-2-eaa2f9b300a2@aspeedtech.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Adds support for the AST2700 PWM/Tach controller by extending the
compatible string enumeration in the device tree binding.
The AST2700 PWM/Tach hardware is compatible with the existing binding
schema and requires no additional properties or modifications beyond
the new compatible string.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20251120-upstream_pwm_tach-v3-1-eaa2f9b300a2@aspeedtech.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Merge series from Andreas Kemnade <andreas@kemnade.info>:
Add a driver for the FP9931/JD9930 regulator which provides the
comparatively high voltages needed for electronic paper displays.
Datasheet for the FP9931 is at
https://www.fitipower.com/dl/file/flXa6hIchVeu0W3K
Although it is in English, it seems to be only downloadable
from the Chinese part of that website.
For the JD9930 there can be a datasheet found at
https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/JD9930_2D00_0.7_2D00_JUN_2D00_2019.pdf
To simplify things, include the hwmon part directly which is only
one register read and there are not other functions besides
regulators in this chip.
The macros IN_FROM_REG, TEMP_FROM_REG, and RPM_FROM_REG evaluate their
arguments multiple times. These macros are used in lockless show functions
involving shared driver data, leading to Time-of-Check to Time-of-Use race
conditions.
For example, RPM_FROM_REG checks if a value is 0 or 255, and then uses it
in a division. If the value is modified by another thread to 0 after the
check but before the division, it causes a divide-by-zero error.
Convert these macros to static functions. This guarantees that arguments
are evaluated only once (pass-by-value), fixing the race conditions.
Adhere to the principle of minimal changes by only converting the specific
macros involved in these lockless contexts.
Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://lore.kernel.org/r/20251120041331.1917570-1-hanguidong02@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Return "PTR_ERR(pca9450->sd_vsel_gpio)" instead of "ret". The "ret"
variable is success at this point.
Fixes: 3ce6f4f943 ("regulator: pca9450: Fix control register for LDO5")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aSBqnPoBrsNB1Ale@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
Members of struct software_node_ref_args should not be dereferenced
directly but set using the provided macros. Commit d7cdbbc93c
("software node: allow referencing firmware nodes") changed the name of
the software node member and caused a build failure. Remove all direct
dereferences of the ref struct as a fix.
However, this driver also seems to abuse the software node interface by
waiting for a node with an arbitrary name "intel-xhci-usb-sw" to appear
in the system before setting up the reference for the I2C device, while
the actual software node already exists in the intel-xhci-usb-role-switch
module and should be used to set up a static reference. Add a FIXME for
a future improvement.
Fixes: d7cdbbc93c ("software node: allow referencing firmware nodes")
Fixes: 53c24c2932 ("platform/x86: intel_cht_int33fe: use inline reference properties")
Cc: stable@vger.kernel.org
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/all/20251121111534.7cdbfe5c@canb.auug.org.au/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
There are two kernel-doc like descriptions at cper, which is used
by other parts of cper and on ghes driver. They both have kernel-doc
like descriptions.
Change the tags for them to be actual kernel-doc tags and add them
to the driver-api documentaion at the UEFI section.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Up to UEFI spec 2.9, the type byte of CPER struct for ARM processor
was defined simply as:
Type at byte offset 4:
- Cache error
- TLB Error
- Bus Error
- Micro-architectural Error
All other values are reserved
Yet, there was no information about how this would be encoded.
Spec 2.9A errata corrected it by defining:
- Bit 1 - Cache Error
- Bit 2 - TLB Error
- Bit 3 - Bus Error
- Bit 4 - Micro-architectural Error
All other values are reserved
That actually aligns with the values already defined on older
versions at N.2.4.1. Generic Processor Error Section.
Spec 2.10 also preserve the same encoding as 2.9A.
Adjust CPER and GHES handling code for both generic and ARM
processors to properly handle UEFI 2.9A and 2.10 encoding.
Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-information
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Compiling with W=1 with werror enabled produces an error:
drivers/firmware/efi/cper-arm.c: In function ‘cper_print_proc_arm’:
drivers/firmware/efi/cper-arm.c:298:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx);
| ^
drivers/firmware/efi/cper-arm.c:298:25: note: ‘snprintf’ output between 2 and 65 bytes into a destination of size 64
298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As the logic there adds an space at the end of infopx buffer.
Add an extra space to avoid such warning.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The ARM processor CPER record was added in UEFI v2.6 and remained
unchanged up to v2.10.
Yet, the original arm_event trace code added by
e9279e83ad ("trace, ras: add ARM processor error trace event")
is incomplete, as it only traces some fields of UAPI 2.6 table N.16, not
exporting any information from tables N.17 to N.29 of the record.
This is not enough for the user to be able to figure out what has
exactly happened or to take appropriate action.
According to the UEFI v2.9 specification chapter N2.4.4, the ARM
processor error section includes:
- several (ERR_INFO_NUM) ARM processor error information structures
(Tables N.17 to N.20);
- several (CONTEXT_INFO_NUM) ARM processor context information
structures (Tables N.21 to N.29);
- several vendor specific error information structures. The
size is given by Section Length minus the size of the other
fields.
In addition, it also exports two fields that are parsed by the GHES
driver when firmware reports it, e.g.:
- error severity
- CPU logical index
Report all of these information to userspace via a the ARM tracepoint so
that userspace can properly record the error and take decisions related
to CPU core isolation according to error severity and other info.
The updated ARM trace event now contains the following fields:
====================================== =============================
UEFI field on table N.16 ARM Processor trace fields
====================================== =============================
Validation handled when filling data for
affinity MPIDR and running
state.
ERR_INFO_NUM pei_len
CONTEXT_INFO_NUM ctx_len
Section Length indirectly reported by
pei_len, ctx_len and oem_len
Error affinity level affinity
MPIDR_EL1 mpidr
MIDR_EL1 midr
Running State running_state
PSCI State psci_state
Processor Error Information Structure pei_err - count at pei_len
Processor Context ctx_err- count at ctx_len
Vendor Specific Error Info oem - count at oem_len
====================================== =============================
It should be noted that decoding of tables N.17 to N.29, if needed, will
be handled in userspace. That gives more flexibility, as there won't be
any need to flood the kernel with micro-architecture specific error
decoding.
Also, decoding the other fields require a complex logic, and should be
done for each of the several values inside the record field. So, let
userspace daemons like rasdaemon decode them, parsing such tables and
having vendor-specific micro-architecture-specific decoders.
[mchehab: modified description, solved merge conflicts and fixed coding style]
Signed-off-by: Jason Tian <jason@os.amperecomputing.com>
Co-developed-by: Shengwei Luo <luoshengwei@huawei.com>
Signed-off-by: Shengwei Luo <luoshengwei@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Daniel Ferguson <danielf@os.amperecomputing.com> # rebased
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Shiju Jose <shiju.jose@huawei.com>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Fixes: e9279e83ad ("trace, ras: add ARM processor error trace event")
Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Call vfio_pci_core_fill_phys_vec() with the proper physical ranges for the
synthetic BAR 2 and BAR 4 regions. Otherwise use the normal flow based on
the PCI bar.
This demonstrates a DMABUF that follows the region info report to only
allow mapping parts of the region that are mmapable. Since the BAR is
power of two sized and the "CXL" region is just page aligned the there can
be a padding region at the end that is not mmaped or passed into the
DMABUF.
The "CXL" ranges that are remapped into BAR 2 and BAR 4 areas are not PCI
MMIO, they actually run over the CXL-like coherent interconnect and for
the purposes of DMA behave identically to DRAM. We don't try to model this
distinction between true PCI BAR memory that takes a real PCI path and the
"CXL" memory that takes a different path in the p2p framework for now.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Alex Mastro <amastro@fb.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Reviewed-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-11-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Add support for exporting PCI device MMIO regions through dma-buf,
enabling safe sharing of non-struct page memory with controlled
lifetime management. This allows RDMA and other subsystems to import
dma-buf FDs and build them into memory regions for PCI P2P operations.
The implementation provides a revocable attachment mechanism using
dma-buf move operations. MMIO regions are normally pinned as BARs
don't change physical addresses, but access is revoked when the VFIO
device is closed or a PCI reset is issued. This ensures kernel
self-defense against potentially hostile userspace.
Currently VFIO can take MMIO regions from the device's BAR and map
them into a PFNMAP VMA with special PTEs. This mapping type ensures
the memory cannot be used with things like pin_user_pages(), hmm, and
so on. In practice only the user process CPU and KVM can safely make
use of these VMA. When VFIO shuts down these VMAs are cleaned by
unmap_mapping_range() to prevent any UAF of the MMIO beyond driver
unbind.
However, VFIO type 1 has an insecure behavior where it uses
follow_pfnmap_*() to fish a MMIO PFN out of a VMA and program it back
into the IOMMU. This has a long history of enabling P2P DMA inside
VMs, but has serious lifetime problems by allowing a UAF of the MMIO
after the VFIO driver has been unbound.
Introduce DMABUF as a new safe way to export a FD based handle for the
MMIO regions. This can be consumed by existing DMABUF importers like
RDMA or DRM without opening an UAF. A following series will add an
importer to iommufd to obsolete the type 1 code and allow safe
UAF-free MMIO P2P in VM cases.
DMABUF has a built in synchronous invalidation mechanism called
move_notify. VFIO keeps track of all drivers importing its MMIO and
can invoke a synchronous invalidation callback to tell the importing
drivers to DMA unmap and forget about the MMIO pfns. This process is
being called revoke. This synchronous invalidation fully prevents any
lifecycle problems. VFIO will do this before unbinding its driver
ensuring there is no UAF of the MMIO beyond the driver lifecycle.
Further, VFIO has additional behavior to block access to the MMIO
during things like Function Level Reset. This is because some poor
platforms may experience a MCE type crash when touching MMIO of a PCI
device that is undergoing a reset. Today this is done by using
unmap_mapping_range() on the VMAs. Extend that into the DMABUF world
and temporarily revoke the MMIO from the DMABUF importers during FLR
as well. This will more robustly prevent an errant P2P from possibly
upsetting the platform.
A DMABUF FD is a preferred handle for MMIO compared to using something
like a pgmap because:
- VFIO is supported, including its P2P feature, on archs that don't
support pgmap
- PCI devices have all sorts of BAR sizes, including ones smaller
than a section so a pgmap cannot always be created
- It is undesirable to waste a lot of memory for struct pages,
especially for a case like a GPU with ~100GB of BAR size
- We want a synchronous revoke semantic to support FLR with light
hardware requirements
Use the P2P subsystem to help generate the DMA mapping. This is a
significant upgrade over the abuse of dma_map_resource() that has
historically been used by DMABUF exporters. Experience with an OOT
version of this patch shows that real systems do need this. This
approach deals with all the P2P scenarios:
- Non-zero PCI bus_offset
- ACS flags routing traffic to the IOMMU
- ACS flags that bypass the IOMMU - though vfio noiommu is required
to hit this.
There will be further work to formalize the revoke semantic in
DMABUF. For now this acts like a move_notify dynamic exporter where
importer fault handling will get a failure when they attempt to map.
This means that only fully restartable fault capable importers can
import the VFIO DMABUFs. A future revoke semantic should open this up
to more HW as the HW only needs to invalidate, not handle restartable
faults.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-10-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
For pen and stylus, the ABS_Z event reports ABS_DISTANCE values
in the hid generic kernel driver. This test is to make sure that
the assignment is properly done for all pen and stylus tools.
Same as tilt, distance is an optional event.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Tatsunosuke Tobit <tatsunosuke.tobita@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
HID_GD_Z is mapped to ABS_Z for stylus and pen in hid-input.c. But HID_GD_Z
should be used to report ABS_DISTANCE for stylus and pen as described at:
Documentation/input/event-codes.rst#n226
* ABS_DISTANCE:
- Used to describe the distance of a tool from an interaction surface. This
event should only be emitted while the tool is hovering, meaning in close
proximity of the device and while the value of the BTN_TOUCH code is 0. If
the input device may be used freely in three dimensions, consider ABS_Z
instead.
- BTN_TOOL_<name> should be set to 1 when the tool comes into detectable
proximity and set to 0 when the tool leaves detectable proximity.
BTN_TOOL_<name> signals the type of tool that is currently detected by the
hardware and is otherwise independent of ABS_DISTANCE and/or BTN_TOUCH.
This patch makes the correct mapping. The ABS_DISTANCE is currently not mapped
by any HID usage in hid-generic driver.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Cc: stable@kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Make sure that all VFIO PCI devices have peer-to-peer capabilities
enables, so we would be able to export their MMIO memory through DMABUF,
VFIO has always supported P2P mappings with itself. VFIO type 1
insecurely reads PFNs directly out of a VMA's PTEs and programs them
into the IOMMU allowing any two VFIO devices to perform P2P to each
other.
All existing VMMs use this capability to export P2P into a VM where
the VM could setup any kind of DMA it likes. Projects like DPDK/SPDK
are also known to make use of this, though less frequently.
As a first step to more properly integrating VFIO with the P2P
subsystem unconditionally enable P2P support for VFIO PCI devices. The
struct p2pdma_provider will act has a handle to the P2P subsystem to
do things like DMA mapping.
While real PCI devices have to support P2P (they can't even tell if an
IOVA is P2P or not) there may be fake PCI devices that may trigger
some kind of catastrophic system failure. To date VFIO has never
tripped up on such a case, but if one is discovered the plan is to add
a PCI quirk and have pcim_p2pdma_init() fail. This will fully block
the broken device throughout any users of the P2P subsystem in the
kernel.
Thus P2P through DMABUF will follow the historical VFIO model and be
unconditionally enabled by vfio-pci.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Alex Mastro <amastro@fb.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-9-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
There is no need to share the main device pointer (struct vfio_device *)
with all the feature functions as they only need the core device
pointer. Therefore, extract the core device pointer once in the
caller (vfio_pci_core_ioctl_feature) and share it instead.
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Alex Mastro <amastro@fb.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-8-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
These helpers are useful for managing additional references taken
on the device from other associated VFIO modules.
Original-patch-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Alex Mastro <amastro@fb.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-7-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Add dma_buf_phys_vec_to_sgt() and dma_buf_free_sgt() helpers to convert
an array of MMIO physical address ranges into scatter-gather tables with
proper DMA mapping.
These common functions are a starting point and support any PCI
drivers creating mappings from their BAR's MMIO addresses. VFIO is one
case, as shortly will be RDMA. We can review existing DRM drivers to
refactor them separately. We hope this will evolve into routines to
help common DRM that include mixed CPU and MMIO mappings.
Compared to the dma_map_resource() abuse this implementation handles
the complicated PCI P2P scenarios properly, especially when an IOMMU
is enabled:
- Direct bus address mapping without IOVA allocation for
PCI_P2PDMA_MAP_BUS_ADDR, using pci_p2pdma_bus_addr_map(). This
happens if the IOMMU is enabled but the PCIe switch ACS flags allow
transactions to avoid the host bridge.
Further, this handles the slightly obscure, case of MMIO with a
phys_addr_t that is different from the physical BAR programming
(bus offset). The phys_addr_t is converted to a dma_addr_t and
accommodates this effect. This enables certain real systems to
work, especially on ARM platforms.
- Mapping through host bridge with IOVA allocation and DMA_ATTR_MMIO
attribute for MMIO memory regions (PCI_P2PDMA_MAP_THRU_HOST_BRIDGE).
This happens when the IOMMU is enabled and the ACS flags are forcing
all traffic to the IOMMU - ie for virtualization systems.
- Cases where P2P is not supported through the host bridge/CPU. The
P2P subsystem is the proper place to detect this and block it.
Helper functions fill_sg_entry() and calc_sg_nents() handle the
scatter-gather table construction, splitting large regions into
UINT_MAX-sized chunks to fit within sg->length field limits.
Since the physical address based DMA API forbids use of the CPU list
of the scatterlist this will produce a mangled scatterlist that has
a fully zero-length and NULL'd CPU list. The list is 0 length,
all the struct page pointers are NULL and zero sized. This is stronger
and more robust than the existing mangle_sg_table() technique. It is
a future project to migrate DMABUF as a subsystem away from using
scatterlist for this data structure.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Alex Mastro <amastro@fb.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-6-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Reflect latest changes in p2p implementation to support DMABUF lifecycle.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-5-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Provide an access to pci_p2pdma_map_type() function to allow subsystems
to determine the appropriate mapping type for P2PDMA transfers between
a provider and target device.
The pci_p2pdma_map_type() function is the core P2P layer version of
the existing public, but struct page focused, pci_p2pdma_state()
function. It returns the same result. It is required to use the p2p
subsystem from drivers that don't use the struct page layer.
Like __pci_p2pdma_update_state() it is not an exported function. The
idea is that only subsystem code will implement mapping helpers for
taking in phys_addr_t lists, this is deliberately not made accessible
to every driver to prevent abuse.
Following patches will use this function to implement a shared DMA
mapping helper for DMABUF.
Tested-by: Alex Mastro <amastro@fb.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-4-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Refactor the PCI P2PDMA subsystem to separate the core peer-to-peer DMA
functionality from the optional memory allocation layer. This creates a
two-tier architecture:
The core layer provides P2P mapping functionality for physical addresses
based on PCI device MMIO BARs and integrates with the DMA API for
mapping operations. This layer is required for all P2PDMA users.
The optional upper layer provides memory allocation capabilities
including gen_pool allocator, struct page support, and sysfs interface
for user space access.
This separation allows subsystems like DMABUF to use only the core P2P
mapping functionality without the overhead of memory allocation features
they don't need. The core functionality is now available through the
new pcim_p2pdma_provider() function that returns a p2pdma_provider
structure.
Tested-by: Alex Mastro <amastro@fb.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-3-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Update the pci_p2pdma_bus_addr_map() function to take a direct pointer
to the p2pdma_provider structure instead of the pci_p2pdma_map_state.
This simplifies the API by removing the need for callers to extract
the provider from the state structure.
The change updates all callers across the kernel (block layer, IOMMU,
DMA direct, and HMM) to pass the provider pointer directly, making
the code more explicit and reducing unnecessary indirection. This
also removes the runtime warning check since callers now have direct
control over which provider they use.
Tested-by: Alex Mastro <amastro@fb.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-2-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Currently the P2PDMA code requires a pgmap and a struct page to
function. The was serving three important purposes:
- DMA API compatibility, where scatterlist required a struct page as
input
- Life cycle management, the percpu_ref is used to prevent UAF during
device hot unplug
- A way to get the P2P provider data through the pci_p2pdma_pagemap
The DMA API now has a new flow, and has gained phys_addr_t support, so
it no longer needs struct pages to perform P2P mapping.
Lifecycle management can be delegated to the user, DMABUF for instance
has a suitable invalidation protocol that does not require struct page.
Finding the P2P provider data can also be managed by the caller
without need to look it up from the phys_addr.
Split the P2PDMA code into two layers. The optional upper layer,
effectively, provides a way to mmap() P2P memory into a VMA by
providing struct page, pgmap, a genalloc and sysfs.
The lower layer provides the actual P2P infrastructure and is wrapped
up in a new struct p2pdma_provider. Rework the mmap layer to use new
p2pdma_provider based APIs.
Drivers that do not want to put P2P memory into VMA's can allocate a
struct p2pdma_provider after probe() starts and free it before
remove() completes. When DMA mapping the driver must convey the struct
p2pdma_provider to the DMA mapping code along with a phys_addr of the
MMIO BAR slice to map. The driver must ensure that no DMA mapping
outlives the lifetime of the struct p2pdma_provider.
The intended target of this new API layer is DMABUF. There is usually
only a single p2pdma_provider for a DMABUF exporter. Most drivers can
establish the p2pdma_provider during probe, access the single instance
during DMABUF attach and use that to drive the DMA mapping.
DMABUF provides an invalidation mechanism that can guarantee all DMA
is halted and the DMA mappings are undone prior to destroying the
struct p2pdma_provider. This ensures there is no UAF through DMABUFs
that are lingering past driver removal.
The new p2pdma_provider layer cannot be used to create P2P memory that
can be mapped into VMA's, be used with pin_user_pages(), O_DIRECT, and
so on. These use cases must still use the mmap() layer. The
p2pdma_provider layer is principally for DMABUF-like use cases where
DMABUF natively manages the life cycle and access instead of
vmas/pin_user_pages()/struct page.
In addition, remove the bus_off field from pci_p2pdma_map_state since
it duplicates information already available in the pgmap structure.
The bus_offset is only used in one location (pci_p2pdma_bus_addr_map)
and is always identical to pgmap->bus_offset.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Alex Mastro <amastro@fb.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Ankit Agrawal <ankita@nvidia.com>
Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-1-d7f71607f371@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
* Extend software node implementation, allowing its properties to reference
existing firmware nodes.
* Update the GPIO property interface to use reworked swnode macros.
* Rework reset-gpio code to use GPIO lookup via swnode.
* Fix spi-cs42l43 driver to work with swnode changes.
-----BEGIN PGP SIGNATURE-----
iI0EABYKADUWIQRRO6F6WdpH1R0vGibVhaclGDdiwAUCaR878xcccC56YWJlbEBw
ZW5ndXRyb25peC5kZQAKCRDVhaclGDdiwBu+AQCw1iTmGlzqT+PqEXvWljTZeVDJ
GViCOX5rRSTTyuq8FwEAp6ToNopfJunQ/XQRdKHC0OX/aYtxo3eYI82LG9meSQ8=
=AMsz
-----END PGP SIGNATURE-----
Merge tag 'reset-gpio-for-v6.19' of https://git.pengutronix.de/git/pza/linux into gpio/for-next
Reset/GPIO/swnode changes for v6.19
* Extend software node implementation, allowing its properties to reference
existing firmware nodes.
* Update the GPIO property interface to use reworked swnode macros.
* Rework reset-gpio code to use GPIO lookup via swnode.
* Fix spi-cs42l43 driver to work with swnode changes.
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
This patch continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This specific workload do not benefit from a per-cpu workqueue, so use
the default unbound workqueue (system_dfl_wq) instead.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251106145003.245866-1-marco.crivellari@suse.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add compatible entry in spidev describing in Arduino UnoQ single-board
computer the interface between Qualcomm QRB2210 microprocessor and
STMicroelectronics STM32U585 microcontroller.
It is handled in user space by the arduino-router service.
Signed-off-by: Riccardo Mereu <r.mereu@arduino.cc>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://patch.msgid.link/20251120155825.121483-4-r.mereu.kernel@arduino.cc
Signed-off-by: Mark Brown <broonie@kernel.org>
Add unoq mcu interface. It describes an iterface between Qualcomm
QRB2210 microprocessor and STMicroelectronics STM32U585 microcontroller
on Arduino UnoQ single-board computer.
This is a trivial device since it's usage is handled in user space
by the arduino-router service.
Signed-off-by: Riccardo Mereu <r.mereu@arduino.cc>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://patch.msgid.link/20251120155825.121483-3-r.mereu.kernel@arduino.cc
Signed-off-by: Mark Brown <broonie@kernel.org>
Document the compatible for ANV32C81W 256kb Serial SPI non-volatile SRAM.
Although it is a SRAM device, it can be accessed through EEPROM interface.
At least until there is no proper SRAM driver support for it.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20251118121513.88352-1-marex@nabladev.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Add a driver for the FP9931/JD9930 regulator. Implement handling of the PG
(power good), TS_EN (temperature sensor enable), and EN (enable regulators)
pins. Implement the pair of symmetric LDOs as a single regulator because
they share a single voltage set register. For simplicity, just add the
temperature sensor (depending on external NTC) directly.
Limitations:
- As these regulators are controlled together with the VCOM regulator via
the EN pin, some kind of management must be in place. As the enable op
is not called when the regulator is already enabled, simple refcounting
seems not to work to avoid clearing EN when one regulator is still
enabled. As these regulators are typically used together, this
limitation should not hurt hard, just provide the is_enabled op.
- As the VCOM step is quite odd (5V/255 steps), rounding is needed.
Due to some limitations in the regulator core, the max/min voltages in
the devicetree must match the idea of the driver how to round things
exactly.
- Night mode is not implemented, so only the FP9931 compatible is needed in
the driver, there is no REGULATOR_MODE_NIGHT and no clear definition in
the datasheet what it does, also the XON pin which seems to be an input
related to that night mode is not used.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://patch.msgid.link/20251115-fp9931-submit-v3-3-92f5d0772b68@kemnade.info
Signed-off-by: Mark Brown <broonie@kernel.org>
Document the FP9931/JD9930. As the FP9931 is a clear subset of the JD9930,
define it as a fallback compatible. GPIO names are same as in the datasheet
except for the EN pad which is described as "enable".
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://patch.msgid.link/20251115-fp9931-submit-v3-2-92f5d0772b68@kemnade.info
Signed-off-by: Mark Brown <broonie@kernel.org>
Add Fitipower Integrated Technology Inc. to the vendor prefixes.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://patch.msgid.link/20251115-fp9931-submit-v3-1-92f5d0772b68@kemnade.info
Signed-off-by: Mark Brown <broonie@kernel.org>
GPIO machine lookup is a nice mechanism for associating GPIOs with
consumers if we don't know what kind of device the GPIO provider is or
when it will become available. However in the case of the reset-gpio, we
are already holding a reference to the device and so can reference its
firmware node. Let's setup a software node that references the relevant
GPIO and attach it to the auxiliary device we're creating.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
As the reset-gpio devices are purely virtual and never instantiated from
real firmware nodes, let's convert the driver to using the - more
fitting - auxiliary bus.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Auxiliary devices really do need a parent so ahead of converting the
reset-gpios driver to registering on the auxiliary bus, make the GPIO
device that provides the reset GPIO the parent of the reset-gpio device.
To that end move the lookup of the GPIO device by fwnode to the
beginning of __reset_add_reset_gpio_device() which has the added benefit
of bailing out earlier, before allocating resources for the virtual
device, if the chip is not up yet.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
For better readability and easier maintenance order the includes
alphabetically.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
When doing a software node lookup, we require both the fwnode that
references a GPIO chip as well as the node associated with that chip to
be software nodes. However, we now allow referencing generic firmware
nodes from software nodes in driver core so we should allow the same in
GPIO core. Make the software node name check optional and dependent on
whether the referenced firmware node is a software node. If it's not,
just continue with the lookup.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
On some systems the cs42l43 has amplifiers attached to its SPI
controller that are not properly defined in ACPI. Currently
software nodes are added to support this case, however, the chip
selects for these devices are specified using a hack. A software
node is added with the same name as the pinctrl driver, as the
look up was name based, this allowed the GPIO look up to return
the pinctrl driver even though the swnode was not owned by it.
This was necessary as the swnodes did not support directly
linking to real firmware nodes.
Since commit e5d527be7e ("gpio: swnode: don't use the swnode's
name as the key for GPIO lookup") changed the lookup to be
fwnode based this hack will no longer find the pinctrl driver,
resulting in the driver not probing. There is no pinctrl driver
attached to the swnode itself. But other patches did add support
for linking a swnode to a real fwnode node [1]. As such the hack
is no longer needed, so switch over to just passing the real
fwnode for the pinctrl property to avoid any issues.
[Bartosz:
- remove unneeded Fixes: tag,
- use PROPERTY_ENTRY_REF_ARRAY() instead of PROPERTY_ENTRY_REF_ARRAY_LEN()]
Link: https://lore.kernel.org/linux-gpio/20251106-reset-gpios-swnodes-v6-0-69aa852de9e4@linaro.org/ [1]
Fixes: 439fbc9750 ("spi: cs42l43: Add bridged cs35l56 amplifiers")
Cc: stable+noautosel@kernel.org # Don't backport, previous approach works, fix relies on swnode changes
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
At the moment software nodes can only reference other software nodes.
This is a limitation for devices created, for instance, on the auxiliary
bus with a dynamic software node attached which cannot reference devices
the firmware node of which is "real" (as an OF node or otherwise).
Make it possible for a software node to reference all firmware nodes in
addition to static software nodes. To that end: add a second pointer to
struct software_node_ref_args of type struct fwnode_handle. The core
swnode code will first check the swnode pointer and if it's NULL, it
will assume the fwnode pointer should be set.
Software node graphs remain the same, as in: the remote endpoints still
have to be software nodes.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Once we allow software nodes to reference other kinds of firmware nodes,
the node in args will no longer necessarily be a software node so bump
its reference count using its fwnode interface.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Once we allow software nodes to reference all kinds of firmware nodes,
the refnode here will no longer necessarily be a software node so read
its proprties going through its fwnode implementation.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
We could go to the USB consortium, but it's probably
easier that way.
And update HID usage table json generated file from
https://usb.org/sites/default/files/hut1_6.pdf updated: 01/30/2025
Reported-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/191
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Same issues with a secondary tip switch instead of secondary barrel
switch as the Kamvas 19.
Copy the stable Kamvas 19 support back into testing and add the vid/pid
for the Kamvas 27.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/189
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
When pressing the phsyical eraser button (remapped by us to the
Secondary Barrel Switch) while the tip is down, the device
gives us several false reports with a Tip Switch 0:
press| |release
SBS: [0 0 ... 1 1 1 ... 1 0 0 0 0 0 0 ...]
TS: [1 1 ... 1 0 1 ... 1 1 0 0 0 1 1 ...]
In both press/release the number of Tip Switch 0 reports can be up to 4
and *sometimes* the Tip Switch is released in the same report
as the button press/release event.
Paper over this by forcing the tip down for a few reports if it was down
before the button toggled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/195
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Modifies report to have tablet buttons report as buttons, rather than as
keyboard key combinations. The dial is also converted to a relative
input, using the dedicated bit previously reserved for modifier key
information.
Signed-off-by: Hannah Pittman <dev@hannahl.co.uk>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/203
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
This device needs a fix for the tilt range on the pen report descriptor
and the usual conversion of the pad keys from the firmware's hardcoded
keyboard shortcuts to actual pad buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/185
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Several bugs as outlined in udev-hid-bpf#66 and udev-hid-bpf!198:
- pressure curve is far from linear
- tilt range is ±60, not ±127
- pressing the second button sets both tip down and
barrel switch
Fix the second button by adding a Secondary Barrel Switch in the
existing padding and check for the tip down/barrel switch down combo.
When both values become true at the same time, set the Secondary Barrel
Switch instead.
Implement a custom pressure curve that maps the hardware range 0-102
linearly to the logical range 0-1224, and maps the hardware range
103-2047 logarithmically to the logical range 1232-2047. This mapping
isn’t perfect, but it’s way more natural than the stock configuration.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jan Felix Langenbach <JanFelix.Langenbach@protonmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/200
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The 3Dconnexion SpaceNavigator HID report descriptor declares its axis
data to be "relative" when it is actually "absolute". This quirk was
addressed in the kernel in 2.6.33, but some SpaceNavigator variants have
a slightly different report descriptor whose axis input items are at
different offsets than those assumed by the kernel fixup.
Add a BPF fixup to handle both sets of offsets for known SpaceNavigator
variants if the descriptor has not already been fixed by the kernel.
Signed-off-by: Curran Muhlberger <curran@cs.cornell.edu>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/181
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Another Huion Kamvas tablet support.
Again it's safer to duplicate the code source in a separate file to
ensure we are not breaking any existing device.
Signed-off-by: Higgins Dragon <higgins@higginsdragon.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/207
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
This assumes that the tablet has been switched into vendor mode (by
using huion-switcher[1], for example) and is sending events using
Huion's proprietary data format.
This has been tested using the PW600L pen, which does not have an
eraser. There is no expectation that a pen with an eraser will work at
this time.
[1] https://github.com/whot/huion-switcher
Signed-off-by: Nicholas LaPointe <nicholaslapointe8@gmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/162
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
There are a differences in the report descriptor to the existing
Inspiroy 2S which makes having this as separate file a more efficient
approach than merging them together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/167
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The timepulse pin is an output that can be used to generate a pulse at a
(configurable) frequency (i.e. it is not an input).
Fixes: dba529605f ("dt-bindings: gnss: Rewrite common bindings in YAML")
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
The u-blox company name is written in lowercase so restore the style
that was used before the binding was converted to YAML.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
The RESET_N and SAFEBOOT_N pins should typically be left open and only
be connected to ground in rare cases where a device is misbehaving.
Specify GPIO_OPEN_DRAIN in the example as this is what should generally
be used.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
U-Blox M8/M9 chip have a pin to start it in safeboot mode, to be used
to recover from situations where the flash content has become
corrupted and needs to be restored. If this pin is asserted at power
up/reset, the receiver starts in safeboot mode and GNSS operation is
disabled.
Deassert the safeboot pin when probing this driver.
Signed-off-by: Alejandro Enrique <alejandroe1@geotab.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250911-ubx-safeboot-v3-2-32fe6b882a3c@geotab.com
[ johan: deassert after requesting supplies ]
Signed-off-by: Johan Hovold <johan@kernel.org>
This hardware block amongst other things includes a multiplexer for a
high-speed Combo-Phy. This binding allows exposing the multiplexer
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251115-openwrt-one-network-v4-1-48cbda2969ac@collabora.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add an auxiliary (aux) device to support RoCE. The base driver is
responsible for creating the auxiliary device and allocating the
required resources to it, which will be owned by the bnge RoCE
driver in future patches.
Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
Link: https://patch.msgid.link/20251117171136.128193-2-siva.kallam@broadcom.com
Reviewed-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Driver is not creating the debugfs hooks for CQ coalesc parameters
because of a wrong check. Fixed the condition check inside
bnxt_re_init_cq_coal_debugfs().
Fixes: cf27490790 ("RDMA/bnxt_re: Add a debugfs entry for CQE coalescing tuning")
Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Link: https://patch.msgid.link/20251117061306.1140588-1-kalesh-anakkur.purayil@broadcom.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
The PWM signal from the LPG channel can be routed to PMIC GPIOs with
proper GPIO configuration, and it is not necessary to enable the
TRILED channel in that case. This also applies to the LPG channels
that mapped to TRILED channels. Additionally, enabling the TRILED
channel unnecessarily would cause a voltage increase in its power
supply. Hence remove it.
Fixes: 24e2d05d1b ("leds: Add driver for Qualcomm LPG")
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://patch.msgid.link/20251119-lpg_triled_fix-v3-2-84b6dbdc774a@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
LPG channels can be used for only outputting PWM signals by routing to
PMIC GPIOs without enabling TRILED. Explain this usage in the description
for better clarity.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://patch.msgid.link/20251119-lpg_triled_fix-v3-1-84b6dbdc774a@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
The 'leds' node is missing constraints on additional properties. It is
mixing 'leds' node and child node properties as well as missing some
properties. Add the 'led@' child nodes and the missing properties.
Fixes: 1160f9f88b ("dt-bindings: mfd: fsl,mc13xxx: Convert txt to DT schema")
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251118213541.43812-1-robh@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
When reading the fdt_size value, the argument passed to dt_mem_next_cell()
is dt_root_addr_cells, but it should be dt_root_size_cells.
The same issue occurs when reading the scratch_size value.
Use a helper function to simplify the code and fix these issues.
Fixes: 274cdcb1c0 ("arm64: add KHO support")
Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev>
Link: https://patch.msgid.link/20251115134753.179931-5-yuntao.wang@linux.dev
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The len value is in bytes, while `dt_root_addr_cells + dt_root_size_cells`
is in cells (4 bytes per cell). Modulo calculation between them is
incorrect, the units must be converted first.
Use helper functions to simplify the code and fix this issue.
Fixes: fb319e77a0 ("of: fdt: Add memory for devices by DT property "linux,usable-memory-range"")
Fixes: 2af2b50acf ("of: fdt: Add generic support for handling usable memory range property")
Fixes: 8f579b1c4e ("arm64: limit memory regions based on DT property, usable-memory-range")
Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev>
Link: https://patch.msgid.link/20251115134753.179931-4-yuntao.wang@linux.dev
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The len value is in bytes, while `dt_root_addr_cells + dt_root_size_cells`
is in cells (4 bytes per cell). Comparing them directly is incorrect.
Use a helper function to simplify the code and address this issue.
Fixes: f7e7ce93aa ("of: fdt: Add generic support for handling elf core headers property")
Fixes: e62aaeac42 ("arm64: kdump: provide /proc/vmcore file")
Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev>
Link: https://patch.msgid.link/20251115134753.179931-3-yuntao.wang@linux.dev
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Currently, there are many pieces of nearly identical code scattered across
different places. Consolidate the duplicate code into helper functions to
improve maintainability and reduce the likelihood of errors.
Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev>
Link: https://patch.msgid.link/20251115134753.179931-2-yuntao.wang@linux.dev
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
There's nothing special about RGB multi-led instances. Allow any color
combinations by simply extending the "if _RGB" checks.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: David Heidelberg <david@ixit.cz>
Link: https://patch.msgid.link/20251117-topic-lpg_multi-v1-1-05604374a2dd@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
If devm_request_threaded_irq() fails after irq_domain_add_linear()
succeeds in mt6358_irq_init(), the function returns without removing
the created IRQ domain, leading to a resource leak.
Call irq_domain_remove() in the error path after a successful
irq_domain_add_linear() to properly release the IRQ domain.
Fixes: 2b91c28f2a ("mfd: Add support for the MediaTek MT6358 PMIC")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20251118121427.583-1-vulab@iscas.ac.cn
Signed-off-by: Lee Jones <lee@kernel.org>
If devm_request_threaded_irq() fails after irq_domain_create_linear()
succeeds in mt6397_irq_init(), the function returns without removing
the created IRQ domain, leading to a resource leak.
Call irq_domain_remove() in the error path after a successful
irq_domain_create_linear() to properly release the IRQ domain.
Fixes: a4872e80ce ("mfd: mt6397: Extract IRQ related code from core driver")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20251118121500.605-1-vulab@iscas.ac.cn
Signed-off-by: Lee Jones <lee@kernel.org>
The sfrbu on both sama7g5 and sama6d65 both fall back to sama5d2 in
devicetrees, but the former two compatibles were undocumented. Now that
syscon.yaml has easy support for multiple soc-specific compatibles, add
both of these undocumented devices.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251117-marlin-mustang-5ffda4d211c7@spud
Signed-off-by: Lee Jones <lee@kernel.org>
On pic64gx these syscons are identical to those on mpfs, and should use
a fallback. Add support for multiple fallback compatibles to syscon.yaml
with these as the first two users.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251117-aeration-smock-5e7ac06e2942@spud
Signed-off-by: Lee Jones <lee@kernel.org>
Currently, during suspend, do nothing; during resume, just sync the
regmap cache to hw regs.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://lore.kernel.org/r/20251119140455.10096-1-jszhang@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The 16Z034 and 16Z037 are 8 bits GPIO controllers that share the
same registers and features of the 16Z127 GPIO controller.
Signed-off-by: Jose Javier Rodriguez Barbarin <dev-josejavier.rodriguez@duagon.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251118083115.9545-1-dev-josejavier.rodriguez@duagon.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Convert dlg,da9052-i2c.txt to yaml format.
Additional changes:
- compatible string fallback to dlg,da9052 to align existing dts files.
- Add interrupts property.
- Add ref to /schemas/spi/spi-peripheral-props.yaml#
- Add dlg,da9053bc.
Remove dlg,da9053 from trivial-devices.yaml.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251114213037.1211907-1-Frank.Li@nxp.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for optional GPIO-based enable pin control to PWM LED driver.
Some PWM LED driver chips like TPS92380 and LT3743 require a separate
enable signal in addition to PWM control. Implement support for such
GPIO control through the "enable-gpios" device tree property, activating
the pin when LED brightness is non-zero and deactivating it when off.
Tested on i.MX8MP EVK with TPS92380 LED driver chip
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
Link: https://patch.msgid.link/20251117054511.730246-2-Qing-wu.Li@leica-geosystems.com.cn
Signed-off-by: Lee Jones <lee@kernel.org>
Some PWM LED driver chips like TPS92380 and LT3743 require a separate
enable signal in addition to PWM control. Add this property to allow
device trees to specify such GPIO, which will be controlled
automatically by the driver based on the LED brightness state.
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251117054511.730246-1-Qing-wu.Li@leica-geosystems.com.cn
Signed-off-by: Lee Jones <lee@kernel.org>
Commit d373449d8e ("iommu/vt-d: Use the generic iommu page table")
changed the calculation of domain::aperture_end. Previously, it was
calculated as:
domain->domain.geometry.aperture_end =
__DOMAIN_MAX_ADDR(domain->gaw - 1);
where domain->gaw was limited to less than MGAW.
Currently, it is calculated purely based on the max level of the page
table that the hardware supports. This is incorrect as stated in Section
3.6 of the VT-d spec:
"Software using first-stage translation structures to translate an IO
Virtual Address (IOVA) must use canonical addresses. Additionally,
software must limit addresses to less than the minimum of MGAW and the
lower canonical address width implied by FSPM (i.e., 47-bit when FSPM
is 4-level and 56-bit when FSPM is 5-level)."
Restore the previous calculation method for domain::aperture_end to avoid
violating the spec. Incorrect aperture calculation causes GPU hangs
without generating VT-d faults on some Intel client platforms.
Fixes: d373449d8e ("iommu/vt-d: Use the generic iommu page table")
Reported-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Closes: https://lore.kernel.org/r/4f15cf3b-6fad-4cd8-87e5-6d86c0082673@intel.com
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Suggested-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Invalidation hint (ih) in the function 'qi_desc_iotlb' is initialized
to zero and never used. It is embedded in the 0th bit of the 'addr'
parameter. Get the correct 'ih' value from there.
Fixes: f701c9f36b ("iommu/vt-d: Factor out invalidation descriptor composition")
Signed-off-by: Aashish Sharma <aashish@aashishsharma.net>
Link: https://lore.kernel.org/r/20251009010903.1323979-1-aashish@aashishsharma.net
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
INTEL_IOMMU_FLOPPY_WA workaround was introduced to create direct mappings
for first 16MB for floppy devices as the floppy drivers were not using
dma apis. We need not do this direct map if floppy driver is not
enabled.
INTEL_IOMMU_FLOPPY_WA is generally not a good idea. Iommu will be
mapping pages in this address range while kernel would also be
allocating from this range(mostly on memory stress). A misbehaving
device using this domain will have access to the pages that the
kernel might be actively using. We noticed this while running a test
that was trying to figure out if any pages used by kernel is in iommu
page tables.
This patch reduces the scope of the above issue by disabling the
workaround when floppy driver is not enabled. But we would still need to
fix the floppy driver to use dma apis so that we need not do direct map
without reserving the pages. Or the other option is to reserve this
memory range in firmware so that kernel will not use the pages.
Fixes: d850c2ee5f ("iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions")
Fixes: 49a0429e53 ("Intel IOMMU: Iommu floppy workaround")
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Link: https://lore.kernel.org/r/20251002161625.1155133-1-vineeth@bitbyteword.org
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
On S2MPG10 (and similar like S2MPG11), top-level interrupt status and
mask registers exist which need to be unmasked to get the PMIC
interrupts. This additional status doesn't seem to exist on other PMICs
in the S2MP* family, and the S2MPG10 driver is manually dealing with
masking and unmasking currently.
The correct approach here is to register this hierarchy as chained
interrupts, though, without any additional manual steps. Doing so will
also simplify addition of other, similar, PMICs (like S2MPG11) in the
future.
Update the driver to do just that.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20251114-s2mpg10-chained-irq-v1-1-34ddfa49c4cd@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Further investigation revealed that the MCU in QNAP devices may return
two error states. One "@8" for a checksum error in the submitted command
and one "@9" for any generic (and sadly unspecified) error.
These error codes with 2 data character can of course also be shorter
then the expected reply length for the submitted command, so we'll
need to check the received data for error codes and exit the receive
portion early in that case.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251113165218.449616-5-heiko@sntech.de
Signed-off-by: Lee Jones <lee@kernel.org>
We'll need the checksum check in a second place in the future, so
move the verification code to a separate function.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251113165218.449616-4-heiko@sntech.de
Signed-off-by: Lee Jones <lee@kernel.org>
EPROTO stands for protocol error and a lot of driver already use it
to designate errors in the sent or received data from a peripheral.
So use it in the qnap-mcu as well for checksum errors.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251113165218.449616-3-heiko@sntech.de
Signed-off-by: Lee Jones <lee@kernel.org>
In the case of an error message, the number of received bytes can be
less than originally expected but still contain a valid message.
If the transfer itself ended in an error we would exit earlier already.
So calculate the checksum on the number of received bytes and not the
number of expected bytes.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251113165218.449616-2-heiko@sntech.de
Signed-off-by: Lee Jones <lee@kernel.org>
Merge series from Bartosz Golaszewski <brgl@bgdev.pl>:
Problem statement: GPIOs are implemented as a strictly exclusive
resource in the kernel but there are lots of platforms on which single
pin is shared by multiple devices which don't communicate so need some
way of properly sharing access to a GPIO. What we have now is the
GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
doesn't do any locking or arbitration of access - it literally just hand
the same GPIO descriptor to all interested users.
The proposed solution is composed of three major parts: the high-level,
shared GPIO proxy driver that arbitrates access to the shared pin and
exposes a regular GPIO chip interface to consumers, a low-level shared
GPIOLIB module that scans firmware nodes and creates auxiliary devices
that attach to the proxy driver and finally a set of core GPIOLIB
changes that plug the former into the GPIO lookup path.
The changes are implemented in a way that allows to seamlessly compile
out any code related to sharing GPIOs for systems that don't need it.
The practical use-case for this are the powerdown GPIOs shared by
speakers on Qualcomm db845c platform, however I have also extensively
tested it using gpio-virtuser on arm64 qemu with various DT
configurations.
min_t(u16, a, b) casts an 'unsigned long' to 'u16'.
Use min(a, b) instead as it promotes the both values to int
and so cannot discard significant bits.
In this case the values should be ok.
Detected by an extra check added to min_t().
Signed-off-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
As mention in sifive,plic-1.0.0.yaml, a specific compatible should be used
for pic64gx, so here it is.
Signed-off-by: Pierre-Henry Moussay <pierre-henry.moussay@microchip.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251117-evict-corridor-5efe40101eea@spud
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
If an interrupt controller is used as a proxy, it may have an
"interrupt-parent" property, but lack "interrupts" and
"interrupts-extended" properties. In that case, the "interrupt-parent"
property in the interrupt controller node is ignored, causing the
interrupt controller to fail to probe, and leading to system boot
failures or crashes.
Fix this by also considering an explicit "interrupt-parent" property in
the interrupt controller node itself.
Fixes: 1b1f04d827 ("of/irq: Ignore interrupt parent for nodes without interrupts")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/20251118115037.1866871-1-m.szyprowski@samsung.com
Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://lore.kernel.org/b037f67a-b241-4689-9914-57ff578c1454@sirena.org.uk
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/e89669c9b3a4fbac4a972ffadcbe00fddb365472.1763557994.git.geert+renesas@glider.be
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
When the genpd governor for CPUs, tries to select the most optimal idle
state for a group of CPUs managed in a PM domain, it fails far too often.
On a Dragonboard 410c, which is an arm64 based platform with 4 CPUs in one
cluster that is using PSCI OS-initiated mode, we can observe that we often
fail when trying to enter the selected idle state. This is certainly a
suboptimal behaviour that leads to many unnecessary requests being sent to
the PSCI FW.
A simple dd operation that reads from the eMMC, to generate some IRQs and
I/O handling helps us to understand the problem, while also monitoring the
rejected counters in debugfs for the corresponding idle states of the genpd
in question.
Menu governor:
cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states
State Time Spent(ms) Usage Rejected Above Below
S0 1451 437 91 149 0
S1 65194 558 149 172 0
dd if=/dev/mmcblk0 of=/dev/null bs=1M count=500
524288000 bytes (500.0MB) copied, 3.562698 seconds, 140.3MB/s
cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states
State Time Spent(ms) Usage Rejected Above Below
S0 2694 1073 265 892 1
S1 74567 829 561 790 0
The dd completed in ~3.6 seconds and rejects increased with 586.
Teo governor:
cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states
State Time Spent(ms) Usage Rejected Above Below
S0 4976 2096 392 1721 2
S1 160661 1893 1309 1904 0
dd if=/dev/mmcblk0 of=/dev/null bs=1M count=500
524288000 bytes (500.0MB) copied, 3.543225 seconds, 141.1MB/s
cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states
State Time Spent(ms) Usage Rejected Above Below
S0 5192 2194 433 1830 2
S1 167677 2891 3184 4729 0
The dd completed in ~3.6 seconds and rejects increased with 1916.
The main reason to the above problem is pending IPIs for one of the CPUs
that is affected by the idle state that the genpd governor selected. This
leads to that the PSCI FW refuses to enter it. To improve the behaviour,
let's start to take into account pending IPIs for CPUs in the genpd
governor, hence we fallback to use the shallower per CPU idle state.
Re-testing with this change shows a significant improved behaviour.
- Menu governor:
cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states
State Time Spent(ms) Usage Rejected Above Below
S0 2556 878 19 368 1
S1 69974 596 10 152 0
dd if=/dev/mmcblk0 of=/dev/null bs=1M count=500
524288000 bytes (500.0MB) copied, 3.522010 seconds, 142.0MB/s
cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states
State Time Spent(ms) Usage Rejected Above Below
S0 3360 1320 28 819 1
S1 70168 710 11 267 0
The dd completed in ~3.5 seconds and rejects increased with 10.
- Teo governor
cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states
State Time Spent(ms) Usage Rejected Above Below
S0 5145 1861 39 938 1
S1 188887 3117 51 1975 0
dd if=/dev/mmcblk0 of=/dev/null bs=1M count=500
524288000 bytes (500.0MB) copied, 3.653100 seconds, 136.9MB/s
cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states
State Time Spent(ms) Usage Rejected Above Below
S0 5260 1923 42 1002 1
S1 190849 4033 52 2892 0
The dd completed in ~3.7 seconds and rejects increased with 4.
Note that, the rejected counters in genpd are also being accumulated in the
rejected counters that are managed by cpuidle, yet on a per CPU idle states
basis. Comparing these counters before/after this change, through cpuidle's
sysfs interface shows the similar improvements.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When governors used during cpuidle try to find the most optimal idle state
for a CPU or a group of CPUs, they are known to quite often fail. One
reason for this is, that they are not taking into account whether there has
been an IPI scheduled for any of the CPUs that are affected by the selected
idle state.
To enable pending IPIs to be taken into account for cpuidle decisions,
introduce a new helper function, cpus_peek_for_pending_ipi().
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The round_rate() clk ops is deprecated in the clk framework in favor
of the determine_rate() clk ops, so let's convert this driver so that
round_rate() can be removed from the clk core.
Signed-off-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Starting with commit f99508074e ("PM: domains: Detach on
device_unbind_cleanup()"), there is no longer a need to call
dev_pm_domain_detach() in the bus remove function. The
device_unbind_cleanup() function now handles this to avoid
invoking devres cleanup handlers while the PM domain is
powered off, which could otherwise lead to failures as
described in the above-mentioned commit.
Drop the explicit dev_pm_domain_detach() call and rely instead
on the flags passed to dev_pm_domain_attach() to power off the
domain.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
BCM2712 has a PM block but lacks asb and rpivid_asb register
spaces. To avoid unwanted results add a check for asb existence
during probe and also add a new register offset for bcm2712 to
control grafx_v3d power domain. The decision to use the new
register is implicit - if asb register base is null then the
driver is probed for bcm2712 (the other supported SoCs have
asb register space).
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The mtk-mfg pmdomain driver calls common mailbox framework functions. If
the common mailbox framework is not selected in the kernel's
configuration, the build runs into a linker error, as the symbols are
absent.
The hardware mailbox Kconfig system, MAILBOX, has no dependencies of its
own. It's therefore safe to "select" it rather than use "depend on".
Declare this "select" dependency in the Kconfig for the driver.
Fixes: 1ff1f0db6aec ("pmdomain: mediatek: Add support for MFlexGraphics")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510301311.TcOCnZ1s-lkp@intel.com/
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
integration silicon is required to power on the GPU.
This glue silicon is in the form of an embedded microcontroller running
special-purpose firmware, which autonomously adjusts clocks and
regulators.
Implement a driver, modelled as a pmdomain driver with a
set_performance_state operation, to support these SoCs.
The driver also exposes the actual achieved clock rate, as read back
from the MCU, as common clock framework clocks, by acting as a clock
provider as well.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Let's add the missing header to fix the reported build-errors.
Fixes: df4e9ec1ed86 ("pmdomain: mediatek: Add support for secure HWCCF infra power on")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510231317.ZZxNaFG0-lkp@intel.com/
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add support for the HFRPSYS Multimedia power domains found in the
MediaTek MT8196 Chromebook SoC.
Those power domains are all managed by the Hardware Voter MCU.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add a new SPM bus protection block and add support for both the
direct control and HW Voter control SCPSYS power domains found
in the MT8196 and MT6991 SoCs.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some SoCs, like the MediaTek Dimensity 9400 (MT6991), have granular
power controls and will disable power to the infracfg to save power
when the platform is in deeper sleep states (or when no IP in the
the infracfg macro-block is in use).
These chips also cannot control the infracfg power states directly
via AP register writes as those are protected by the secure world.
Add a new MTK_SCPD_INFRA_PWR_CTL cap and, if present, make a call
to the secure world to poweron the infracfg block, as the HWV IP
resides in there, when executing HWV domains power sequences.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
New generation SoCs like MT8196/MT6991 feature a new type of power
domains, managed by a Hardware Voter (HWV) helper (through a SoC
internal fixed-function MCU): this is used to collect votes from
both the AP and the various other remote processors present in the
SoC and transparently power on/off various power domains, avoiding
unpowered access of registers in various internal IPs from all of
the integrated remote processors (or from the AP...!).
Add a new power domain type and differentiate between the old
SCPSYS_MTCMOS_TYPE_DIRECT_CTL - where power domains are controlled
directly by and exclusively from the Application Processor, and
the new SCPSYS_MTCMOS_TYPE_HW_VOTER, where the power domains are
voted through the HWV.
With the two needing different handling, check the power domain
type and assign a different power_{off,on} callback for pm_genpd:
for this specific reason, also move the check for the SCPD cap
MTK_SCPD_KEEP_DEFAULT_OFF after the assignment, and use the
assigned power_on function instead of calling scpsys_power_on()
directly to make that work for both HW_VOTER and DIRECT_CTL.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add the RPMh power domains present in Kaanapali SoCs. Also increase the
maximum allowed number of levels for ARC resources from 16 to 32, as
needed starting on the Kaanapali SoC where the ARC vote registers have been
expanded from 4 to 5 bits.
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
i.MX95 DWC3 inside HSIOMIX could still wakeup Linux, even if HSIOMIX
power domain(Digital logic) is off. There is still always on logic
have the wakeup capability which is out band wakeup capbility.
So use device_set_out_band_wakeup for i.MX95 to make sure DWC3 could
wakeup system even if HSIOMIX power domain is in off state.
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Tested-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Xu Yang <xu.yang_2@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
i.MX95 USB2 inside HSIOMIX could still wakeup Linux, even if HSIOMIX
power domain(Digital logic) is off. There is still always on logic
have the wakeup capability which is out band wakeup capbility.
So use device_set_out_band_wakeup for i.MX95 to make sure usb2 could
wakeup system even if HSIOMIX power domain is in off state.
Tested-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Xu Yang <xu.yang_2@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When add a platform device by calling ci_hdrc_add_device(), this device
will reuse OF node of its parent device. If power-domains property is
provided in the OF node, both two platform devices will be attached to
the same power domain. This should be unnecessary and may bring other
inconsistent behavior. For example, to support wakeup capability, these
two platform device need different power domain state. The parent device
need NOT power domain on for out-band interrupt, but the ci_hdrc device
need power domain on for in-band interrupt. The i.MX95 Soc support
out-band wakeup interrupt, the user need to enable wakeup for the parent
device, but if the user also enable wakeup for ci_hdrc device, the power
domain will keep at on state finally. To exclude such inconsistent
behavior and simplify the power management, detach power domain for ci_hdrc
platform device.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Acked-by: Peter Chen <peter.chen@kernel.org>
Tested-by: Xu Yang <xu.yang_2@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Currently, if a device is configured as a system wakeup source, the PM
domain core avoids powering off its power domain during system-wide
suspend. However, this can lead to unnecessary power consumption,
especially for devices whose wakeup logic resides in an always-on domain,
i.e., devices with out-of-band wakeup capability.
To address this, add a check for device_out_band_wakeup() in
genpd_finish_suspend(). If the device supports out-of-band wakeup, its
power domain can be safely powered off, just like regular devices without
wakeup enabled. And same check in genpd_finish_resume().
This change improves power efficiency without compromising wakeup
functionality.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some devices can wake up the system from suspend even when their power
domains are turned off. This is possible because their system-wakeup logic
resides in an always-on power domain - indicating that they support
out-of-band system wakeup.
Currently, PM domain core doesn't power off such devices if they are marked
as system wakeup sources. To better represent devices with out-of-band
wakeup capability, this patch introduces a new flag out_band_wakeup in
'struct dev_pm_info'.
Two helper APIs are added:
- device_set_out_band_wakeup() - to mark a device as having out-of-band
wakeup capability.
- device_out_band_wakeup() - to query the flag.
Allow the PM core and drivers to distinguish between regular and
out-of-band wakeup sources, enable more accurate power management decision.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Merge the immutable branch dt into next, to allow the DT bindings to be
tested together with changes that are targeted for v6.19.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This is the only Kconfig symbol that depends on OF while selecting the common
driver for several chips. Drop this unneeded dependency and make the component
available on non-OF systems along with wider compile test.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20251111105320.750131-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the
semantic patch at scripts/coccinelle/misc/semicolon.cocci.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20251111052451.3687740-1-nichen@iscas.ac.cn
Signed-off-by: Lee Jones <lee@kernel.org>
Since PCI device should not be abusing platform device, MFD parent to
platform child path is no longer being pursued for this driver. Convert
it to auxiliary driver, which will be used by EHL PSE auxiliary device.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20251112034040.457801-3-raag.jadav@intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
devices that expose two different capabilities of GPIO and Timed I/O
as a single PCI function through shared MMIO with below layout.
GPIO: 0x0000 - 0x1000
TIO: 0x1000 - 0x2000
This driver enumerates the PCI parent device and creates auxiliary child
devices for these capabilities. The actual functionalities are provided
by their respective auxiliary drivers.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20251112034040.457801-2-raag.jadav@intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
GPIOLIB is now aware of shared GPIOs and - for platforms where access to
such pins is managed internally - we don't need to keep track of the
enable count.
Once all users in the kernel switch to using the new mechanism, we'll be
able to drop the internal counting of users from the regulator code.
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20251112-gpio-shared-v4-10-b51f97b1abd8@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
I went through all the datasheets and created this note listing
chip functions and register layouts.
Signed-off-by: Levente Révész <levente.revesz@eilabs.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Link: https://lore.kernel.org/r/20251112224924.2091880-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The .free callback cleared among others the enable bit PWENx in the
control register. When the PWM is requested later again this bit isn't
restored but the core assumes the PWM is enabled and thus skips a
request to configure the same state as before.
To fix that don't touch the hardware configuration in .free(). For
symmetry also drop .request() and configure the mode completely in
.apply().
Fixes: e5a06dc5ac ("pwm: Add BCM2835 PWM driver")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20251118174303.1761577-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The System Management Controller on Apple Silicon devices is responsible
for integrating and exposing the data reported by the vast array of
hardware monitoring sensors present on these devices. It is also
responsible for fan control, and allows users to manually set fan
speeds if they so desire. Add a hwmon driver to expose current,
power, temperature, and voltage monitoring sensors, as well as
fan speed monitoring and control via the SMC on Apple Silicon devices.
The SMC firmware has no consistency between devices, even when they
share an SoC. The FourCC keys used to access sensors are almost
random. An M1 Mac mini will have different FourCCs for its CPU core
temperature sensors to an M1 MacBook Pro, for example. For this
reason, the valid sensors for a given device are specified in a
child of the SMC Devicetree node. The driver uses this information
to determine which sensors to make available at runtime.
Reviewed-by: Neal Gompa <neal@gompa.dev>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Co-developed-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Link: https://lore.kernel.org/r/20251112-macsmc-subdevs-v5-6-728e4b91fe81@gmail.com
[groeck: Added Documentation to index]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
mock_get_event() uses an uninitialized local variable, nr_overflow, to
populate the overflow_err_count field. That results in incorrect
overflow_err_count values in mocked cxl_overflow trace events, such as
this case where the records are reported as 0 and should be non-zero:
[] cxl_overflow: memdev=mem7 host=cxl_mem.6 serial=7: log=Failure : 0 records from 1763228189130895685 to 1763228193130896180
Fix by using log->nr_overflow and remove the unused local variable.
A follow-up change was considered in cxl_mem_get_records_log() to
confirm that the overflow_err_count is non-zero when the overflow flag
is set [1]. Since the driver has no functional dependency on this
constraint, and a device that violates this specific requirement does
not cause incorrect driver behavior, no validation check is added.
[1] CXL 3.2, Table 8-65 Get Event Records Output Payload
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>> ---
Link: https://patch.msgid.link/20251116013036.1713313-1-alison.schofield@intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Commit 364ee9f326 ("cxl/test: Enhance event testing") changed the
loop iterator in mock_get_event() from a static constant,
CXL_TEST_EVENT_CNT, to a dynamic global variable, ret_limit. The
intent was to vary the number of events returned per call to simulate
events occurring while logs are being read.
However, ret_limit is modified without synchronization. When multiple
threads call mock_get_event() concurrently, one thread may read
ret_limit, another thread may increment it, and the first thread's
loop condition and size calculation see and use the updated value.
This is visible during cxl_test module load when all memdevs are
initializing simultaneously, which includes getting event records. It
is not tied to the cxl-events.sh unit test specifically, as that
operates on a single memdev.
While no actual harm results (the buffer is always large enough and
the record count fields correctly reflect what was written), this is
a correctness issue. The race creates an inconsistent state within
mock_get_event() and adding variability based on a race appears
unintended.
Make ret_limit a local variable populated from an atomic counter. Each
call gets a stable value that won't change during execution. That
preserves the intended behavior of varying the return counts across
calls while eliminating the race condition.
This implementation uses "+ 1" to produce the full range of 1 to
CXL_TEST_EVENT_RET_MAX (4) records. Previously only 1, 2, 3 were
produced.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>> ---
Link: https://patch.msgid.link/20251116013819.1713780-1-alison.schofield@intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
The previous code initialized the 'reg' value with specific bus-width
values (BUS_WIDTH_2_BIT and BUS_WIDTH_4_BIT), which introduces ambiguity.
Replace them with BUS_WIDTH_MASK to express the intention clearly.
Fixes: de16c322ee ("spi: sophgo: add SG2044 SPI NOR controller driver")
Signed-off-by: Longbin Li <looong.bin@gmail.com>
Link: https://patch.msgid.link/20251117090559.78288-1-looong.bin@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 733b57f262 ("cxl/pci: Early setup RCH dport component registers from RCRB")
is not necessary under mocking tests.
[ dj: Fixup commit representation flagged by checkpatch. ]
[ dj: Ammend subject line to indicate which function. ]
Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>> ---
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Link: https://patch.msgid.link/20251118182202.2083244-1-alejandro.lucero-palau@amd.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Retrieve the GOP device's EDID information in the kernel's boot
parameters. Makes the data avaialble to kernel graphics code and
drives, such as efidrm.
With efidrm, the EDID is now also available to user-space compositors
via standard DRM interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Add support for EFI_EDID_DISCOVERED_PROTOCOL and EFI_EDID_ACTIVE_PROTOCOL
as defined in UEFI 2.8, sec 12.9. Define GUIDs and data structures in the
rsp header files.
In the GOP setup function, read the EDID of the primary GOP device. First
try EFI_EDID_ACTIVE_PROTOCOL, which supports user-specified EDID data. Or
else try EFI_EDID_DISCOVERED_PROTOCOL, which returns the display device's
native EDID. If no EDID could be retrieved, clear the storage.
Rename efi_setup_gop() to efi_setup_graphics() to reflect the changes
Let callers pass an optional instance of struct edid_data, if they are
interested.
While screen_info and edid_info come from the same device handle, they
should be considered indendent data. The former refers to the graphics
mode, the latter refers to the display device. GOP devices might not
provide both.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Move initialization of screen_info into a single helper function.
Frees up space in the main setup helper for adding EDID support.
No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The device handle of the GOP device is required to retrieve the
correct EDID data. Find the handle instead of the GOP data. Still
return the GOP data in the function arguments, as we already looked
it up.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Resolve an issue with the coding style.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Make the different debounce timers configurable from the devicetree.
Depending on the board design, these have to be set different than the
default register values.
Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
Link: https://patch.msgid.link/20251117202215.1936139-2-martijn.de.gouw@prodrive-technologies.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make the different debounce timers configurable from the devicetree.
Depending on the board design, these have to be set different than the
default register values.
Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251117202215.1936139-1-martijn.de.gouw@prodrive-technologies.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 71c814e986 ("spi: microchip: rename driver file and internal
identifiers") renames spi-microchip-core.c to spi-mpfs.c, but misses to
adjust the file entry in RISC-V MICROCHIP SUPPORT.
Adjust the file entry after this renaming.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Link: https://patch.msgid.link/20251117104044.291517-1-lukas.bulwahn@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Enable 16/32 bits per word support for spi-imx target PIO mode.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20251118065012.1418279-1-carlos.song@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for assert_perst() for switches like TC9563, which require
configuration before the PCIe link is established. Such devices use this
function op to assert PERST# before configuring the device and once the
configuration is done they de-assert PERST#.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251101-tc9563-v9-5-de3429f7787a@oss.qualcomm.com
Controller driver probes first, enables link training and scans the bus.
When the PCI bridge is found, its child DT nodes will be scanned and
pwrctrl devices will be created if needed. By the time pwrctrl driver probe
gets called, link training is already enabled by controller driver.
Certain devices like TC9563, which uses the PCI pwrctl framework, need to
configure the device before the PCIe link is up.
As the controller driver already enables link training as part of its
probe, the moment device is powered on, controller and device participate
in link training and link can come up immediately and may not have time to
configure the device.
So we need to stop the link training by using assert_perst() by asserting
PERST# and de-asserting PERST# after device is configured.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251101-tc9563-v9-2-de3429f7787a@oss.qualcomm.com
Add a device tree binding for the Toshiba TC9563 PCIe switch, which
provides an Ethernet MAC integrated to the 3rd downstream port and
two downstream PCIe ports.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251101-tc9563-v9-1-de3429f7787a@oss.qualcomm.com
In "Packet Format" section, only "StickPointer data byte" subsection
heading is shown as such in htmldocs output; "Touchpad data byte" one
is in normal paragraph on the other hand.
Properly format the headings to be consistent.
Fixes: 2562756dde ("HID: add Alps I2C HID Touchpad-Stick support")
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Add suspend/resume hooks which assert/deassert the reset signals, along
with forcing runtime suspend/resume. This allows using the driver in
scenarios where the resume is done with the help of bootloader and the
bootloader disables the SDHI clocks, resets, IRQs before passing execution
to Linux.
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
SET_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS() require __maybe_unused
or #ifdefs protection against unused function warnings. The usage of
pm_ptr() and SYSTEM_SLEEP_PM_OPS()/RUNTIME_PM_OPS() allows the compiler to
see the functions, thus suppressing the warning. Drop the #ifdefs.
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Deassert the reset signal of the SDHI controller during probe to avoid
relying on the previous bootloaders. Without deasserting the reset signal,
the SDHI controller will not function.
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Common boolean properties need to be only allowed in the binding
(":true"), because their type is already defined by core DT schema.
Simplify dma-coherent property to match common syntax.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The meson-mx-sdio (and mmc core) only support one MMC/SD/SDIO slot
(device) per host. Thus having multiple mmc-slot nodes (one for the up
to three supported slots with one device each on the meson-mx-sdio
hardware) can be problematic.
Allow specifying all slots (with their respective device) connected to
the meson-mx-sdio hardware in device-tree, while making sure that only
the enabled one(s) are actually considered by the driver.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Keep the second line with arguments for dma_unmap_sg() aligned.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This streamlines probe error handling / logging with other drivers.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use new function devm_mmc_alloc_host() to simplify the code.
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use modern common clock framework helpers for simplifying the clock
controller management:
- switch to struct clk_hw for internal clocks and only get the
"cfg_div_clk" (which has to be managed at runtime) as struct clk
using devm_clk_hw_get_clk() which is then the only clock used by
struct meson_mx_mmc_host.
- use CLK_HW_INIT_FW_NAME and CLK_HW_INIT_HW helper macros for simpler
init data initialization
- keep the clock controller memory allocation separate to prevent a
potential use-after-free because struct meson_mx_mmc_host_clkc is
free'd before controller_dev
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This simplifies the code. No functional changes intended.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Switch the driver over to use regmap to access the registers. This makes
it consistent with the other Amlogic MMC drivers. No functional changes
intended.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some SPI controllers like Intel's one on the PCI bus do not support
opcode 35h. This opcode is used to read the Configuration Register on
SPI-NOR chips that have 16-bit Status Register configured regardless
of the controller support for it. Adding a check call in the setup step
allows disabling use of the 35h opcode and falling back to the manual
Status Registers management.
Before:
openat(AT_FDCWD, "/dev/mtd0", O_RDWR) = 4
ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = -1
EOPNOTSUPP
After:
openat(AT_FDCWD, "/dev/mtd0", O_RDWR) = 4
ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = 0
ioctl(4, MIXER_WRITE(5) or MEMLOCK, {start=0x1800000, length=0x800000}) = 0
Suggested-by: Adeel Arshad <adeel.arshad@intel.com>
Signed-off-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
The MT35XU02GCBA flash device does not support chip erase, according to
its datasheet. It supports die erase, which means the current driver
implementation will likely need to be converted to use die erase.
Furthermore, similar to the MT35XU01GBBA, the
SPI_NOR_IO_MODE_EN_VOLATILE flag probably needs to be enabled.
Currently no active contributor has access to this hardware so there is
no way of testing the fixes. Add a TODO item on the flash entry so
someone with the flash can test that the support is indeed broken and
send the fixes.
Link: https://datasheet.octopart.com/MT35XU02GCBA1G12-0AAT-Micron-datasheet-138896808.pdf
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
[pratyush@kernel.org: refactor the comment and commit message to make
the purpose of the comment clearer]
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
mt35xu01gbba is similar with mt35xu512aba, but with two dies.
mt35xu01gbba has SFDP and support 8D-8D-8D mode, but SFDP
lack SNOR_F_IO_MODE_EN_VOLATILE, so add this fixup flags here.
Besides, mt35xu01gbba do not support chip erase, but support
die erase, so add that in late_init().
Link: https://datasheet.octopart.com/MT35XU02GCBA1G12-0AAT-Micron-datasheet-138896808.pdf
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Move params->set_octal_dtr from flash_info->fixups->default_init()
to spi_nor_manufacturer-> fixups-> late_init(), this can cover
all Micorn and ST chips without repeat in each chip's flash_info.
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
st_nor_two/four_die_late_init() also suit for micron chips,
so rename to micron_st_nor_two/four_die_late_init(), and move
these functions up, then micron can use these function without
declaration.
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Merge series from Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>:
This series adds AST2700 support to the ASPEED FMC/SPI driver and
bindings, introduces 64-bit address compatibility, and improves
Quad SPI page programming behavior. It also implements AST2700-specific
segment logic, where range adjustment is not required because the
AST2700 SPI hardware controller already fixes decoding issues on
the existing platforms and adopts an updated scheme.
Update header inclusions to follow IWYU (Include What You Use)
principle.
In particular, replace of_gpio.h, which is subject to removal by the
GPIOLIB subsystem, with the respective headers that are being used by the
driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251114185534.3287497-1-andriy.shevchenko@linux.intel.com
pci_epc_mem_alloc_addr() allocates a CPU address from the ATU window phys
base and a page number. Set the ep->page_size so the resulting CPU address
is correctly aligned with the ATU required alignment.
Fixes: 151f3d29ba ("PCI: stm32-ep: Add PCIe Endpoint support for STM32MP25")
Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
[mani: added fixes tag]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251114-atu_align_ep-v1-1-88da5366fa04@foss.st.com
If the host has deasserted PERST# and started link training before the link
is started on EP side, enabling LTSSM before the endpoint registers are
initialized in the perst_irq handler results in probing incorrect values.
Thus, wait for the PERST# level-triggered interrupt to start link training
at the end of initialization and cleanup the stm32_pcie_[start stop]_link
functions.
Fixes: 151f3d29ba ("PCI: stm32-ep: Add PCIe Endpoint support for STM32MP25")
Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
[mani: added fixes tag]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: wrap line]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251114-perst_ep-v1-1-e7976317a890@foss.st.com
Some of the datasheet links contained .pdf suffix which resulted in 404.
This patch updates the links to the correct URLs on Renesas website.
Signed-off-by: Igor Reznichenko <igor@reznichenko.net>
Link: https://lore.kernel.org/r/20251115182908.1357793-1-igor@reznichenko.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Extended linear cache unit testing support
- Standardize CXL auto region size
- Add cxl_test CFMWS support for extended linear cache
- Add support for acpi extended linear cache
It is a requirement that DT overlays in the kernel are applied at build
time to a base DTB in order to validate they can be applied and to
validate them against the DT schemas. DT overlays on their own may be
incomplete and can't be validated.
Add a kbuild check so this doesn't have to be checked and fixed
periodically.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The Devicetree Specification states:
The root of the interrupt tree is determined when traversal of the
interrupt tree reaches an interrupt controller node without an
interrupts property and thus no explicit interrupt parent.
However, of_irq_init() gratuitously assumes that a node without
interrupts has an actual interrupt parent if it finds an
interrupt-parent property higher up in the device tree. Hence when such
a property is present (e.g. in the root node), the root interrupt
controller may not be detected as such, causing a panic:
OF: of_irq_init: children remain, but no parents
Kernel panic - not syncing: No interrupt controller found.
Commit e91033621d ("of/irq: Use interrupts-extended to find
parent") already fixed a first part, by checking for the presence of an
interrupts-extended property. Fix the second part by only calling
of_irq_find_parent() when an interrupts property is present.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/fbe6fc3657070fe2df7f0529043542b52b827449.1763116833.git.geert+renesas@glider.be
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
There are no longer any board files including the DaVinci SPI platform
data header. Let's move the bits and pieces that are used in the driver
into the driver .c file itself and remove the header.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20251117-davinci-spi-v2-1-cd799d17f04a@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The of_bus_default_match() function appears to have been copied from
of_bus_default_flags_match() with some modifications.
However, the comment was left unchanged and still describes the behavior
of of_bus_default_flags_match(), it is incorrect and misleading, remove it.
Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev>
Fixes: 6e5773d52f ("of/address: Fix WARN when attempting translating non-translatable addresses")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251112143520.233870-11-yuntao.wang@linux.dev
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The binding is already defined in mfd/stericsson,db8500-prcmu.yaml and none
of 'the tripN.*' properties appear to be in use.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251030195234.439141-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the brcm,sr-thermal binding to DT schema format. It's a
straight-forward conversion. "polling-delay", "thermal-sensors", and
"temperature" all apply to the thermal zones, not the sensor node.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251013215810.783006-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
For better readability, it is recommended to insert a newline before the
'status' property. Adjust the examples accordingly.
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251023-docs-dt-newline-v1-1-1bf5e0040c0b@ixit.cz
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Generally at most 1 blank line is the standard style for DT schema
files. Remove the few cases with more than 1 so that the yamllint check
for this can be enabled.
Acked-by: Lee Jones <lee@kernel.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> # remoteproc
Acked-by: Georgi Djakov <djakov@kernel.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Uwe Kleine-König <ukleinek@kernel.org> # for allwinner,sun4i-a10-pwm.yaml
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> # mtd
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org> # For PCI controller bindings
Link: https://patch.msgid.link/20251023143957.2899600-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the existing text-based DT bindings for MediaTek MT8173 Media Data
Path to a DT schema.
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251001183115.83111-1-ariel.dalessandro@collabora.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
LGE LG131x SoCs have been in use for some time, but the root compatibles
have not been documented. Add them.
Acked-by: Chanho Min <chanho.min@lge.com>
Link: https://patch.msgid.link/20251022181144.4147944-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
yamllint has gained a new check which checks for inconsistent quoting
(mixed " and ' quotes within a file). Fix all the cases yamllint found
so we can enable the check (once the check is in a release). As single
quotes are (slightly) preferred, use them throughout the modified files
even if double quotes are mostly used.
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20251015232015.846282-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the Actions S500/S700/S900 Smart Power System binding to DT
schema format. It's a straight-forward conversion.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251013215834.783501-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Add a compatible for the MediaTek MT8365 SoC, that has an integrated
ARM Mali G52 MC1 GPU and compatible with arm,mali-bifrost.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Link: https://patch.msgid.link/20251021-mt8365-enable-gpu-v2-1-17e05cff2c86@collabora.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Update Altera socfpga-ecc-manager dt bindings maintainer from
<matthew.gerlach@altera.com> to <niravkumarlaxmidas.rabara@altera.com>
as Matthew Gerlack is moving out of Altera.
Signed-off-by: Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com>
Acked-by: Matthew Gerlach <matthew.gerlach@altera.com>
Link: https://patch.msgid.link/20251017083849.3213192-1-niravkumarlaxmidas.rabara@altera.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Node names are already and properly checked by the core schema. No need
to do it again.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20251020060951.30776-7-wsa+renesas@sang-engineering.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Fix a dt-schema error: `fsl,imx6q-vdoa.yaml:19:12: [error] string value is
redundantly quoted with any quotes (quoted-strings)`
Signed-off-by: Erick Setubal Bacurau <erick.setubal@gmx.de>
Link: https://patch.msgid.link/20251020121145.190020-1-erick.setubal@gmx.de
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Add compatible string "fsl,imx95-irqsteer" for the i.MX95 chip, which is
backward compatible with "fsl,imx-irqsteer".
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251011170213.128907-38-marek.vasut@mailbox.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the Marvell AP80x System Controller binding to DT schema format.
There's not any specific compatible for the whole block which is a
separate problem, so just the child nodes are documented. Only the
pinctrl and clock child nodes need to be converted as the GPIO node
already has a schema.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20251014153040.3783896-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the Marvell CP110 System Controller binding to DT schema
format.
There's not any specific compatible for the whole block which is a
separate problem, so just the child nodes are documented. Only the
pinctrl and clock child nodes need to be converted as the GPIO node
already has a schema.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20251022165509.3917655-2-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Add the mock wrappers for hmat_get_extended_linear_cache_size() in order
to emulate the ACPI helper function for the regions that are mock'd by
cxl_test.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Fabio M. De Francesco <fabio.m.de.francesco@linux.intel.com>
Link: https://patch.msgid.link/20251117144611.903692-4-dave.jiang@intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Add a module parameter to allow activation of extended linear cache
on the auto region for cxl_test. The current platform implementation
for extended linear cache is 1:1 of DRAM and CXL memory. A CFMWS is
created with the size of both memory together where DRAM takes the
first part of the memory range and CXL covers the second part. The
current CXL auto region on cxl_test consists of 2 256M devices that
creates a 512M region. The new extended linear cache setup will have
512M DRAM and 512M CXL memory for a total of 1G CFMWS. The hardware
decoders must have their starting offset moved to after the DRAM region
to handle the CXL regions.
[ dj: Fixup commenting style. (Jonathan) ]
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Fabio M. De Francesco <fabio.m.de.francesco@linux.intel.com>
Link: https://patch.msgid.link/20251117144611.903692-3-dave.jiang@intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Create a global define for the size of the mock CXL auto region used
in cxl_test. Remove the declared size in mock_init_hdm_decoder()
function.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Fabio M. De Francesco <fabio.m.de.francesco@linux.intel.com>
Link: https://patch.msgid.link/20251117144611.903692-2-dave.jiang@intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Introduce a driver for the PCIe host controller found in the SpacemiT K1
SoC. The hardware is derived from the Synopsys DesignWare PCIe IP. The
driver supports up to three PCIe ports operating at PCIe link speed up to
5 GT/s. The first port uses a combo PHY, which may be configured for use
for USB3 instead.
Signed-off-by: Alex Elder <elder@riscstar.com>
[mani: added FIXME to the comment on disabling ASPM L1]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Tested-by: Jason Montleon <jmontleo@redhat.com>
Tested-by: Johannes Erdfelt <johannes@erdfelt.com>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Link: https://patch.msgid.link/20251113214540.2623070-6-elder@riscstar.com
Add the Devicetree binding for the PCIe Root Complex found on the SpacemiT
K1 SoC. This Root Complex is derived from the Synopsys Designware PCIe IP.
It supports up to three PCIe ports operating at PCIe link speed up to 5
GT/sec. One of the ports uses a combo PHY, which is typically used to
support a USB3 port.
Signed-off-by: Alex Elder <elder@riscstar.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Tested-by: Jason Montleon <jmontleo@redhat.com>
Tested-by: Johannes Erdfelt <johannes@erdfelt.com>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251113214540.2623070-4-elder@riscstar.com
Power domains and resets should be required for PCI, so the proper SoC
supplies are turned on.
Fixes: 692eadd516 ("dt-bindings: PCI: qcom: Document the X1E80100 PCIe Controller")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251030-dt-bindings-pci-qcom-fixes-power-domains-v2-9-28c1f11599fe@linaro.org
Commit b8d3404058 ("dt-bindings: PCI: qcom,pcie-sm8550: Move SM8550 to
dedicated schema") move the device schema to separate file, but it
missed a "if:not:...then:" clause in the original binding which was
requiring power-domains and resets for this particular chip.
Fixes: b8d3404058 ("dt-bindings: PCI: qcom,pcie-sm8550: Move SM8550 to dedicated schema")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251030-dt-bindings-pci-qcom-fixes-power-domains-v2-8-28c1f11599fe@linaro.org
Commit 88c9b3af4e ("dt-bindings: PCI: qcom,pcie-sm8450: Move SM8450 to
dedicated schema") move the device schema to separate file, but it
missed a "if:not:...then:" clause in the original binding which was
requiring power-domains and resets for this particular chip.
Fixes: 88c9b3af4e ("dt-bindings: PCI: qcom,pcie-sm8450: Move SM8450 to dedicated schema")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251030-dt-bindings-pci-qcom-fixes-power-domains-v2-7-28c1f11599fe@linaro.org
Commit 2278b8b547 ("dt-bindings: PCI: qcom,pcie-sm8350: Move SM8350 to
dedicated schema") move the device schema to separate file, but it
missed a "if:not:...then:" clause in the original binding which was
requiring power-domains and resets for this particular chip.
Fixes: 2278b8b547 ("dt-bindings: PCI: qcom,pcie-sm8350: Move SM8350 to dedicated schema")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251030-dt-bindings-pci-qcom-fixes-power-domains-v2-6-28c1f11599fe@linaro.org
Commit 4891b66185 ("dt-bindings: PCI: qcom,pcie-sm8250: Move SM8250 to
dedicated schema") move the device schema to separate file, but it
missed a "if:not:...then:" clause in the original binding which was
requiring power-domains and resets for this particular chip.
Fixes: 4891b66185 ("dt-bindings: PCI: qcom,pcie-sm8250: Move SM8250 to dedicated schema")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251030-dt-bindings-pci-qcom-fixes-power-domains-v2-5-28c1f11599fe@linaro.org
Commit 51bc04d5b4 ("dt-bindings: PCI: qcom,pcie-sm8150: Move SM8150 to
dedicated schema") move the device schema to separate file, but it
missed a "if:not:...then:" clause in the original binding which was
requiring power-domains and resets for this particular chip.
Fixes: 51bc04d5b4 ("dt-bindings: PCI: qcom,pcie-sm8150: Move SM8150 to dedicated schema")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251030-dt-bindings-pci-qcom-fixes-power-domains-v2-4-28c1f11599fe@linaro.org
Commit c007a55055 ("dt-bindings: PCI: qcom,pcie-sc8280xp: Move
SC8280XP to dedicated schema") move the device schema to separate file,
but it missed a "if:not:...then:" clause in the original binding which
was requiring power-domains and resets for this particular chip.
Fixes: c007a55055 ("dt-bindings: PCI: qcom,pcie-sc8280xp: Move SC8280XP to dedicated schema")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251030-dt-bindings-pci-qcom-fixes-power-domains-v2-3-28c1f11599fe@linaro.org
Commit 756485bfbb ("dt-bindings: PCI: qcom,pcie-sc7280: Move SC7280 to
dedicated schema") move the device schema to separate file, but it
missed a "if:not:...then:" clause in the original binding which was
requiring power-domains and resets for this particular chip.
Fixes: 756485bfbb ("dt-bindings: PCI: qcom,pcie-sc7280: Move SC7280 to dedicated schema")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251030-dt-bindings-pci-qcom-fixes-power-domains-v2-2-28c1f11599fe@linaro.org
Commit 544e8f96ef ("dt-bindings: PCI: qcom,pcie-sa8775p: Move SA8775p
to dedicated schema") move the device schema to separate file, but it
missed a "if:not:...then:" clause in the original binding which was
requiring power-domains and resets for this particular chip.
Fixes: 544e8f96ef ("dt-bindings: PCI: qcom,pcie-sa8775p: Move SA8775p to dedicated schema")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251030-dt-bindings-pci-qcom-fixes-power-domains-v2-1-28c1f11599fe@linaro.org
This adds support for ESMT F50L1G41LC, which appears to be an updated
version of the already supported F50L1G41LB.
Add esmt_8c SPI_NAND manufacturer to account for the newly used vendor
ID with support for the ESMT F50L1G41LC chip.
Link: https://github.com/openwrt/openwrt/pull/15214#issuecomment-3514824435
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The initial fix for a GPIO descriptor leak added manual gpiod_put()
calls in the error path and remove function.
This follow-up patch improves upon the fix by switching to the
resource-managed devm_gpiod_get_optional() API.
Suggested-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Commit 5c2f7727d4 ("mtd: mtdpart: check for subpartitions parsing
result") introduced some kind of regression with parser on subpartitions
where if a parser emits an error then the entire parsing process from the
upper parser fails and partitions are deleted.
Not checking for error in subpartitions was originally intended as
special parser can emit error also in the case of the partition not
correctly init (for example a wiped partition) or special case where the
partition should be skipped due to some ENV variables externally
provided (from bootloader for example)
One example case is the TRX partition where, in the context of a wiped
partition, returns a -ENOENT as the trx_magic is not found in the
expected TRX header (as the partition is wiped)
To better handle this and still keep some kind of error tracking (for
example to catch -ENOMEM errors or -EINVAL errors), permit parser on
subpartition to emit -ENOENT error, print a debug log and skip them
accordingly.
This results in giving better tracking of the status of the parser
(instead of returning just 0, dropping any kind of signal that there is
something wrong with the parser) and to some degree restore the original
logic of the subpartitions parse.
(worth to notice that some special partition might have all the special
header present for the parser and declare 0 partition in it, this is why
it would be wrong to simply return 0 in the case of a special partition
that is NOT init for the scanning parser)
Cc: stable@vger.kernel.org
Fixes: 5c2f7727d4 ("mtd: mtdpart: check for subpartitions parsing result")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The memory allocated for struct pcmciamtd_dev in pcmciamtd_probe() is
not freed in the corresponding remove function pcmciamtd_detach().
Fix that by freeing it in the remove function.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
On Tegra410, Compute and System GPIOs have same port names. This
results in the same GPIO names for both Compute and System GPIOs
during initialization in `tegra186_gpio_probe()`, which results in
following warnings:
kernel: gpio gpiochip1: Detected name collision for GPIO name 'PA.00'
kernel: gpio gpiochip1: Detected name collision for GPIO name 'PA.01'
kernel: gpio gpiochip1: Detected name collision for GPIO name 'PA.02'
kernel: gpio gpiochip1: Detected name collision for GPIO name 'PB.00'
kernel: gpio gpiochip1: Detected name collision for GPIO name 'PB.01'
...
Add GPIO name prefix in the SoC data and use it to initialize the GPIO
name.
Port names remain unchanged for previous SoCs. On Tegra410, Compute
GPIOs are named COMPUTE-P<PORT>.GPIO, and System GPIOs are named
SYSTEM-P<PORT>.GPIO.
Fixes: 9631a10083 ("gpio: tegra186: Add support for Tegra410")
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20251113163112.885900-1-kkartik@nvidia.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Allow to kill devm_gpio_request_one() independently by converting it
to use legacy APIs that will be alive a bit longer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20251112093608.1481030-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Make sure we kill gpio_request_one() first by converting it to
use legacy APIs that will be alive a bit longer. In particular,
this also shows the code we will use in another function to make
it die independently.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20251112093608.1481030-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add better support for GPIOs shared by multiple consumers.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEkeUTLeW1Rh17omX8BZ0uy/82hMMFAmka6jYACgkQBZ0uy/82
hMOiqg//WzGyo1GeTC0Q/xruNMG1Q1dty0O6pQXO0wncg5wa457KBSaDBM8K7xnx
Fmu6gJlyeW8Bgvt4WkMFQPXuKMAGzSuI6buVW4Ncz+cdEYqSCqTV0NLNDottAZgW
HW3jDbGjiKihM4BAweAmH3zutanPw+ZIhVM2EDqRIhWv87oVvxJSMQxrUMzc2E+/
6xGxyPzjukiPM+8hotspP9r6siXdzYSiojiLL7xCalsunz3B3RIrivbHnoWCETcP
Yg0NCjPe/kUjGGuXpB73ZjutzMROpI8lmCY11P1+6PEcQlUIp6UX/YXdHwBLb6bk
ZxpO1x4AkM6YKah2ocY0jQo/u/fKxzTpu8o2hCTUfmqROmM5rrlzXM7NYt/avN6E
ip8dZo+x71GHrjdm7dRN7OSrVL6OFK1AiUPVhuIx0KE7aiKi05thVRknYxA+IYu7
+fatQ2x739ibISvpG6wf9nRPijMXKX2ONU5HKAqtpTAsgsbs07c9ziry/3YBdDWk
YGSenEzlYEPyhzUWQ6gVfbmoCkiG7UUU8WoMfAMpsJhH95VrOAS7WcEhZoq7fDMQ
QMovFUiMbXpBcBu7AFQR3+fKxBXWHdG3Nicsvl5zGyhG3TKv/96umhAYN85J2Dwy
KSJrCLRZg6xN4Ocd1R2Y1NYeJy6LAqx5XgKRD07aqrWnTK8r/uk=
=fa8j
-----END PGP SIGNATURE-----
Merge tag 'gpio/shared-gpios-for-v6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git into gpio/for-next
Immutable branch between the GPIO, ASoC and regulator trees for v6.19-rc1
Add better support for GPIOs shared by multiple consumers.
Some qualcomm platforms use shared GPIOs. Enable support for them by
selecting the Kconfig switch provided by GPIOLIB.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-7-b51f97b1abd8@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Make sure to drop the reference taken to the iommu platform device when
looking up its driver data during probe_device().
Note that commit 9826e393e4 ("iommu/tegra-smmu: Fix missing
put_device() call in tegra_smmu_find") fixed the leak in an error path,
but the reference is still leaking on success.
Fixes: 8918465163 ("memory: Add NVIDIA Tegra memory controller support")
Cc: stable@vger.kernel.org # 3.19: 9826e393e4
Cc: Miaoqian Lin <linmq006@gmail.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Make sure to drop the reference taken to the iommu platform device when
looking up its driver data during of_xlate().
Fixes: 4100b8c229 ("iommu: Add Allwinner H6 IOMMU driver")
Cc: stable@vger.kernel.org # 5.8
Cc: Maxime Ripard <mripard@kernel.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Simplify the probe_device() error handling by dropping the iommu OF node
reference sooner.
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Make sure to drop the references taken to the iommu platform devices
when looking up their driver data during probe_device().
Note that the arch data device pointer added by commit 604629bcb5
("iommu/omap: add support for late attachment of iommu devices") has
never been used. Remove it to underline that the references are not
needed.
Fixes: 9d5018deec ("iommu/omap: Add support to program multiple iommus")
Fixes: 7d6827748d ("iommu/omap: Fix iommu archdata name for DT-based devices")
Cc: stable@vger.kernel.org # 3.18
Cc: Suman Anna <s-anna@ti.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add the missing larb count sanity check to avoid writing beyond a fixed
sized array in case of a malformed devicetree.
Acked-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Make sure to drop the references taken to the larb devices during
probe on probe failure (e.g. probe deferral) and on driver unbind.
Fixes: b17336c55d ("iommu/mediatek: add support for mtk iommu generation one HW")
Cc: stable@vger.kernel.org # 4.8
Cc: Honghui Zhang <honghui.zhang@mediatek.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Make sure to drop the reference taken to the iommu platform device when
looking up its driver data during probe_device().
Fixes: b17336c55d ("iommu/mediatek: add support for mtk iommu generation one HW")
Cc: stable@vger.kernel.org # 4.8
Cc: Honghui Zhang <honghui.zhang@mediatek.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
As previously documented by commit 2659392856 ("iommu/mediatek: Add
error path for loop of mm_dts_parse"), the id mapping may not be linear
so the whole larb array needs to be iterated on devicetree parsing
errors.
Simplify the loop by iterating from index zero while dropping the
redundant NULL check for consistency with later cleanups.
Also add back the comment which was removed by commit 462e768b55
("iommu/mediatek: Fix forever loop in error handling") to prevent anyone
from trying to optimise the loop by iterating backwards from 'i'.
Cc: Yong Wu <yong.wu@mediatek.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The driver is dropping the references taken to the larb devices during
probe after successful lookup as well as on errors. This can
potentially lead to a use-after-free in case a larb device has not yet
been bound to its driver so that the iommu driver probe defers.
Fix this by keeping the references as expected while the iommu driver is
bound.
Fixes: 2659392856 ("iommu/mediatek: Add error path for loop of mm_dts_parse")
Cc: stable@vger.kernel.org
Cc: Yong Wu <yong.wu@mediatek.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Make sure to drop the reference taken to the iommu platform device when
looking up its driver data during of_xlate().
Fixes: 0df4fabe20 ("iommu/mediatek: Add mt8173 IOMMU driver")
Cc: stable@vger.kernel.org # 4.6
Acked-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Make sure to drop the reference taken to the iommu platform device when
looking up its driver data during of_xlate().
Fixes: 7b2d59611f ("iommu/ipmmu-vmsa: Replace local utlb code with fwspec ids")
Cc: stable@vger.kernel.org # 4.14
Cc: Magnus Damm <damm+renesas@opensource.se>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Make sure to drop the reference taken to the iommu platform device when
looking up its driver data during of_xlate().
Note that commit 1a26044954 ("iommu/exynos: add missing put_device()
call in exynos_iommu_of_xlate()") fixed the leak in a couple of error
paths, but the reference is still leaking on success.
Fixes: aa759fd376 ("iommu/exynos: Add callback for initializing devices from device tree")
Cc: stable@vger.kernel.org # 4.2: 1a26044954
Cc: Yu Kuai <yukuai3@huawei.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Make sure to drop the reference taken to the iommu platform device when
looking up its driver data during of_xlate().
Note that commit e2eae09939 ("iommu/qcom: add missing put_device()
call in qcom_iommu_of_xlate()") fixed the leak in a couple of error
paths, but the reference is still leaking on success and late failures.
Fixes: 0ae349a0f3 ("iommu/qcom: Add qcom_iommu")
Cc: stable@vger.kernel.org # 4.14: e2eae09939
Cc: Rob Clark <robin.clark@oss.qualcomm.com>
Cc: Yu Kuai <yukuai3@huawei.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Make sure to drop the reference taken to the iommu platform device when
looking up its driver data during of_xlate().
Fixes: 46d1fb072e ("iommu/dart: Add DART iommu driver")
Cc: stable@vger.kernel.org # 5.15
Cc: Sven Peter <sven@kernel.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
In review comment for v1 of genpt documentation fixes [1], Randy
suggested that pt_test_sw_bit_acquire() parameters description
should be written using "to read". Commit e4dfaf25df ("iommupt:
Describe @bitnr parameter"), however, misunderstood the review by
instead using "to read" on @bitnr parameter on both
pt_test_sw_bit_acquire() and pt_test_sw_bit_release().
Actually correct the description.
[1]: https://lore.kernel.org/linux-doc/9dba0eb7-6f32-41b7-b70b-12379364585f@infradead.org/
Fixes: e4dfaf25df ("iommupt: Describe @bitnr parameter")
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Extend the driver to support the AST2700 SPI controller. Compared to
AST2600, AST2700 has the following characteristics:
- A 64-bit memory address space.
- A 64KB address decoding unit.
- Segment registers now use (start <= range < end) semantics,
which differs slightly from (start <= range <= end) in AST2600.
- Known issues related to address decoding range registers have been
resolved, and the decoding range is now 1GB, which is sufficient.
Therefore, the adjust_window callback is no longer required on AST2700
for range adjustment and bug fixes.
- The SPI clock divider method and timing calibration logic remain
unchanged from AST2600.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Link: https://patch.msgid.link/20251114101042.1520997-5-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Update bus address types from u32 to phys_addr_t to support systems with
64-bit memory address space. This change ensures compatibility with
upcoming SoCs that extend the system bus beyond 32-bit, while maintaining
support for existing platforms.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Link: https://patch.msgid.link/20251114101042.1520997-4-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add AST2700 to the list of supported SoCs in the ASPEED FMC/SPI bindings.
AST2700 FMC/SPI controllers are not compatible with AST2600 due to the
following hardware differences:
- Address decoding unit uses 64KB granularity (AST2600 uses 1MB).
- Segment register semantics are changed.
AST2600: start <= range <= end
AST2700: start <= range < end
- Hardware limitations in AST2600 address decoding registers have been
resolved in AST2700, so extra callback function used for bug fixup
is no longer required.
These differences require distinct compatible strings for AST2700.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251114101042.1520997-2-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Ensure the controller switches to quad I/O mode when
spi-tx-bus-width dts property is 4 and the Quad SPI program
opcode (32h or 34h) is used. Without this change, high-bit
data will be lost during page programming.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Link: https://patch.msgid.link/20251114101042.1520997-3-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
PCIe r7.0, sec 7.8.6, defines resizable BAR sizes beyond the currently
supported maximum of 128TB, which will require more than u32 to store the
entire bitmask.
Convert Resizable BAR related functions to use u64 bitmask for BAR sizes to
make the typing more future-proof.
The support for the larger BAR sizes themselves is not added at this point.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20251113180053.27944-12-ilpo.jarvinen@linux.intel.com
Use pci_rebar_get_max_size() to simplify amdgpu_device_resize_fb_bar().
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20251113180053.27944-11-ilpo.jarvinen@linux.intel.com
Use pci_rebar_get_max_size() from PCI core in resize_vram_bar() to simplify
code.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20251113180053.27944-10-ilpo.jarvinen@linux.intel.com
Add pci_rebar_get_max_size() to allow simplifying code that wants to know
the maximum possible size for a Resizable BAR.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20251113180053.27944-9-ilpo.jarvinen@linux.intel.com
PCI core provides pci_rebar_size_supported() and pci_rebar_size_to_bytes();
use them in resize_vram_bar() to simplify code.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20251113180053.27944-8-ilpo.jarvinen@linux.intel.com
PCI core provides pci_rebar_size_supported() that helps in checking if an
encoded BAR Size is supported for the BAR or not. Use it in
i915_resize_lmem_bar() to simplify code.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20251113180053.27944-7-ilpo.jarvinen@linux.intel.com
Many callers of pci_rebar_get_possible_sizes() are interested in finding
out if a particular encoded BAR Size (PCIe r7.0, sec 7.8.6.3) is supported
by the particular BAR.
Add pci_rebar_size_supported() into PCI core to make it easy for the
drivers to determine if the BAR size is supported or not.
Use the new function in pci_resize_resource() and in
pci_iov_vf_bar_set_size().
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patch.msgid.link/20251113180053.27944-6-ilpo.jarvinen@linux.intel.com
Fix the copy-pasted errors in the Resizable BAR handling functions kernel
doc and generally improve wording choices.
Fix the formatting errors of the Return: line.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20251113180053.27944-5-ilpo.jarvinen@linux.intel.com
pci_rebar_size_to_bytes() is in drivers/pci/pci.h but would be useful for
endpoint drivers as well.
Move the function to rebar.c and export it.
In addition, convert the literal to where the number comes from
(PCI_REBAR_MIN_SIZE).
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20251113180053.27944-4-ilpo.jarvinen@linux.intel.com
Move pci_rebar_bytes_to_size() from include/linux/pci.h to rebar.c as it
does not look very trivial and is not expected to be performance critical.
Convert literals to use a newly added PCI_REBAR_MIN_SIZE define.
Also add kernel doc for the function as the function is exported.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michael J. Ruhl <mjruhl@habana.ai>
Link: https://patch.msgid.link/20251113180053.27944-3-ilpo.jarvinen@linux.intel.com
For lack of a better place to put it, Resizable BAR code has been placed
inside pci.c and setup-res.c that do not use it for anything. Upcoming
changes are going to add more Resizable BAR related functions, increasing
the code size.
As pci.c is huge as is, move the Resizable BAR related code and the BAR
resize code from setup-res.c to rebar.c.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20251113180053.27944-2-ilpo.jarvinen@linux.intel.com
restore_dev_resource() copies saved addresses and flags from the struct
pci_dev_resource back to the struct resource, typically, during rollback
from a failure or in preparation for a retry attempt.
If the resource is within resource tree, the resource must not be
modified as the resource tree could be corrupted. Thus, it's a bug to
call restore_dev_resource() for assigned resources (which did happen
due to logic flaws in the BAR resize rollback).
Add WARN_ON_ONCE() into restore_dev_resource() to detect such bugs easily
and return without altering the resource to prevent corruption.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU
Link: https://patch.msgid.link/20251113162628.5946-12-ilpo.jarvinen@linux.intel.com
PCI core handles releasing device's resources and their rollback in case of
failure of a BAR resizing operation. Releasing resource prior to calling
pci_resize_resource() prevents PCI core from restoring the BARs as they
were.
Remove driver-side release of BARs from the amdgpu driver.
Also remove the driver initiated assignment as pci_resize_resource() should
try to assign as much as possible. If the driver side call manages to get
more required resources assigned in some scenario, such a problem should be
fixed inside pci_resize_resource() instead.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU
Link: https://patch.msgid.link/20251113162628.5946-11-ilpo.jarvinen@linux.intel.com
PCI core handles releasing device's resources and their rollback in case of
failure of a BAR resizing operation. Releasing resource prior to calling
pci_resize_resource() prevents PCI core from restoring the BARs as they
were.
Remove driver-side release of BARs from the i915 driver.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patch.msgid.link/20251113162628.5946-10-ilpo.jarvinen@linux.intel.com
PCI core handles releasing device's resources and their rollback in case of
failure of a BAR resizing operation. Releasing resource prior to calling
pci_resize_resource() prevents PCI core from restoring the BARs as they
were.
Remove driver-side release of BARs from the xe driver.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patch.msgid.link/20251113162628.5946-9-ilpo.jarvinen@linux.intel.com
As pci_resize_resource() is meant to be used also outside of PCI core,
document the interface with kerneldoc.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU
Link: https://patch.msgid.link/20251113162628.5946-8-ilpo.jarvinen@linux.intel.com
BAR resize operation is implemented in the pci_resize_resource() and
pbus_reassign_bridge_resources() functions. pci_resize_resource() can be
called either from __resource_resize_store() from sysfs or directly by the
driver for the Endpoint Device.
The pci_resize_resource() requires that caller has released the device
resources that share the bridge window with the BAR to be resized as
otherwise the bridge window is pinned in place and cannot be changed.
pbus_reassign_bridge_resources() rolls back resources if the resize
operation fails, but rollback is performed only for the bridge windows.
Because releasing the device resources are done by the caller of the BAR
resize interface, these functions performing the BAR resize do not have
access to the device resources as they were before the resize.
pbus_reassign_bridge_resources() could try __pci_bridge_assign_resources()
after rolling back the bridge windows as they were, however, it will not
guarantee the resource are assigned due to differences in how FW and the
kernel assign the resources (alignment of the start address and tail).
To perform rollback robustly, the BAR resize interface has to be altered to
also release the device resources that share the bridge window with the BAR
to be resized.
Also, remove restoring from the entries failed list as saved list should
now contain both the bridge windows and device resources so the extra
restore is duplicated work.
Some drivers (currently only amdgpu) want to prevent releasing some
resources. Add exclude_bars param to pci_resize_resource() and make amdgpu
pass its register BAR (BAR 2 or 5), which should never be released during
resize operation. Normally 64-bit prefetchable resources do not share a
bridge window with the 32-bit only register BAR, but there are various
fallbacks in the resource assignment logic which may make the resources
share the bridge window in rare cases.
This change (together with the driver side changes) is to counter the
resource releases that had to be done to prevent resource tree corruption
in the ("PCI: Release assigned resource before restoring them") change. As
such, it likely restores functionality in cases where device resources were
released to avoid resource tree conflicts which appeared to be "working"
when such conflicts were not correctly detected by the kernel.
Reported-by: Simon Richter <Simon.Richter@hogyros.de>
Link: https://lore.kernel.org/linux-pci/f9a8c975-f5d3-4dd2-988e-4371a1433a60@hogyros.de/
Reported-by: Alex Bennée <alex.bennee@linaro.org>
Link: https://lore.kernel.org/linux-pci/874irqop6b.fsf@draig.linaro.org/
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[bhelgaas: squash amdgpu BAR selection from
https://lore.kernel.org/r/20251114103053.13778-1-ilpo.jarvinen@linux.intel.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20251113162628.5946-7-ilpo.jarvinen@linux.intel.com
Freeing the saved list does not require holding pci_bus_sem, so the
critical section can be made shorter.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU
Link: https://patch.msgid.link/20251113162628.5946-6-ilpo.jarvinen@linux.intel.com
Usually, resizing BARs requires releasing bridge windows in order to
resize it to fit a larger BAR into the window. This is not always the
case, however, FW could have made the window large enough to accommodate
larger BAR as is, or the user might prefer to shrink a BAR to make more
space for another Resizable BAR.
Thus, replace the check that requires that at least one bridge window
was released with a check that simply ensures bridge is not NULL.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU
Link: https://patch.msgid.link/20251113162628.5946-5-ilpo.jarvinen@linux.intel.com
Upcoming fix to BAR resize will store also device BAR resource in the
saved list. Change the pci_dev variable in the loop from 'bridge' to
'dev' as the former would be misleading with non-bridges in the list.
This is in a separate change to reduce churn in the upcoming BAR resize
fix.
While it appears that the logic in the loop doing pci_setup_bridge() is
altered as 'bridge' variable is no longer updated, a bridge should never
appear more than once in the saved list so the check can only match to the
first entry. As such, the code with two distinct pci_dev variables better
represents the intention of the check compared with the old code where
bridge variable was reused for a different purpose.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Link: https://patch.msgid.link/20251113162628.5946-4-ilpo.jarvinen@linux.intel.com
pci_rebar_set_size() adjusts BAR size for both normal and IOV BARs. The
struct pci_sriov keeps a cached copy of BAR size in ->barsz[] which is not
adjusted by pci_rebar_set_size() but by pci_iov_resource_set_size().
pci_iov_resource_set_size() is called also from
pci_resize_resource_set_size().
The current arrangement is problematic once BAR resize algorithm starts to
roll back changes properly in case of a failure. The normal resource
fitting algorithm rolls back resource size using the struct
pci_dev_resource easily but also calling pci_resize_resource_set_size() or
pci_iov_resource_set_size() to roll back BAR size would be an extra burden,
whereas combining ->barsz[] update with pci_rebar_set_size() naturally
rolls back it when restoring the old BAR size on a different layer of the
BAR resize operation.
Thus, rework pci_rebar_set_size() to also update ->barsz[].
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU
Link: https://patch.msgid.link/20251113162628.5946-3-ilpo.jarvinen@linux.intel.com
pbus_reassign_bridge_resources() saves bridge windows into the saved
list before attempting to adjust resource assignments to perform a BAR
resize operation. If resource adjustments cannot be completed fully,
rollback is attempted by restoring the resource from the saved list.
The rollback, however, does not check whether the resources it restores were
assigned by the partial resize attempt. If restore changes addresses of the
resource, it can result in corrupting the resource tree.
An example of a corrupted resource tree with overlapping addresses:
6200000000000-6203fbfffffff : pciex@620c3c0000000
6200000000000-6203fbff0ffff : PCI Bus 0030:01
6200020000000-62000207fffff : 0030:01:00.0
6200000000000-6203fbff0ffff : PCI Bus 0030:02
A resource that are assigned into the resource tree must remain
unchanged. Thus, release such a resource before attempting to restore
and claim it back.
For simplicity, always do the release and claim back for the resource
even in the cases where it is restored to the same address range.
Note: this fix may "break" some cases where devices "worked" because
the resource tree corruption allowed address space double counting to
fit more resource than what can now be assigned without double
counting. The upcoming changes to BAR resizing should address those
scenarios (to the extent possible).
Fixes: 8bb705e3e7 ("PCI: Add pci_resize_resource() for resizing BARs")
Reported-by: Simon Richter <Simon.Richter@hogyros.de>
Link: https://lore.kernel.org/linux-pci/67840a16-99b4-4d8c-9b5c-4721ab0970a2@hogyros.de/
Reported-by: Alex Bennée <alex.bennee@linaro.org>
Link: https://lore.kernel.org/linux-pci/874irqop6b.fsf@draig.linaro.org/
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU
Link: https://patch.msgid.link/20251113162628.5946-2-ilpo.jarvinen@linux.intel.com
Simplify the code by removing local variable @inc. The variable is not
used elsewhere, remove it and directly increment the target number.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Robert Richter <rrichter@amd.com>
Link: https://patch.msgid.link/20251114075844.1315805-4-rrichter@amd.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Simplify the xor arithmetric setup code by grouping it in a single
block. No need to split the block for QoS setup.
It is safe to reorder the call of cxl_setup_extended_linear_cache()
because there are no dependencies.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Robert Richter <rrichter@amd.com>
Tested-by: Gregory Price <gourry@gourry.net>
Link: https://patch.msgid.link/20251114075844.1315805-3-rrichter@amd.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
A root decoder's callback handlers are collected in struct cxl_rd_ops.
The structure is dynamically allocated, though it contains only a few
pointers in it. This also requires to check two pointes to check for
the existence of a callback.
Simplify the allocation, release and handler check by embedding the
ops statically in struct cxl_root_decoder.
Implementation is equivalent to how struct cxl_root_ops handles the
callbacks.
[ dj: Fix spelling error in commit log. ]
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Robert Richter <rrichter@amd.com>
Link: https://patch.msgid.link/20251114075844.1315805-2-rrichter@amd.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Move the Cadence PCIe controller RP common functions into a separate file.
The common library functions are split from legacy PCIe RP controller
functions to a separate file.
Signed-off-by: Manikandan K Pillai <mpillai@cadence.com>
[mani: removed the unused variable]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251108140305.1120117-4-hans.zhang@cixtech.com
Split the Cadence PCIe header file by moving the Legacy (LGA) controller
register definitions to a separate header file for support of next
generation PCIe controller architecture.
Signed-off-by: Manikandan K Pillai <mpillai@cadence.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251108140305.1120117-3-hans.zhang@cixtech.com
Merge series from Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>:
This patch series adds support for the Microchip FPGA CoreSPI "soft" IP
and documents its device tree bindings.
As preparation, the existing Microchip SPI driver is renamed to clearly
indicate that it supports only the Microchip PolarFire SoC "hard" controller.
Although it was originally named with the expectation that it might also
cover the FPGA CoreSPI "soft" IP, the register layouts differ significantly,
so separate drivers are required.
Merge series from Jun Guo <jun.guo@cixtech.com>:
The Cadence SPI IP supports configurable FIFO data widths during
integration. On some SoCs, the FIFO data width is designed to be 16 or
32 bits at the chip design stage. However, the current driver only
supports communication with an 8-bit FIFO data width. Therefore, these
patches are added to enable the driver to support communication with
16-bit and 32-bit FIFO data widths.
Introduce driver support for the Microchip FPGA CoreSPI IP.
This driver supports only Motorola SPI mode and frame size of 8-bits.
TI/NSC modes and wider frame sizes are not currently supported.
Signed-off-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251114104545.284765-4-prajna.rajendrakumar@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add device tree bindings for Microchip's CoreSPI controller.
CoreSPI is a "soft" IP core intended for FPGA implementations. Its
configurations are set in Libero. These properties represent
non-discoverable configurations determined by Verilog parameters to the
IP.
Signed-off-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251114104545.284765-3-prajna.rajendrakumar@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The spi-microchip-core.c driver provides support for the Microchip
PolarFire SoC (MPFS) "hard" SPI controller. It was originally named
"core" with the expectation that it might also cover Microchip's
CoreSPI "soft" IP, but that never materialized.
The CoreSPI IP cannot be supported by this driver because its register
layout differs substantially from the MPFS SPI controller. In practice
most of the code would need to be replaced to handle those differences
so keeping the drivers separate is the simpler approach.
The file and internal symbols are renamed to reflect MPFS support and
to free up "spi-microchip-core.c" for CoreSPI driver.
Fixes: 9ac8d17694 ("spi: add support for microchip fpga spi controllers")
Signed-off-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251114104545.284765-2-prajna.rajendrakumar@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
U-Blox M8/M9 chip have a pin to start it in safeboot mode, to be used
to recover from situations where the flash content has become
corrupted and needs to be restored.
Signed-off-by: Alejandro Enrique <alejandroe1@geotab.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the
semantic patch at scripts/coccinelle/misc/semicolon.cocci.
This was introduced in commit 3a4a308c069a ("pwm: mediatek: Convert to
waveform API").
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20251105214847.1279520-1-nichen@iscas.ac.cn
[ukleinek: Add reference to introducing commit.]
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Introduce driver for PWM module available on EN7581 SoC.
Limitations:
- Only 8 concurrent waveform generators are available for 8 combinations of
duty_cycle and period. Waveform generators are shared between 16 GPIO
pins and 17 SIPO GPIO pins.
- Supports only normal polarity.
- On configuration the currently running period is completed.
- Minimum supported period is 4 ms
- Maximum supported period is 1s
Signed-off-by: Benjamin Larsson <benjamin.larsson@genexis.eu>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Co-developed-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://patch.msgid.link/20251013103408.14724-1-ansuelsmth@gmail.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Implement the new waveform callbacks which makes the usage of this
hardware more flexible and allows to use it via the pwm character
device.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20251013114258.149260-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Duty steps computation can never end in values higher than
MAX7360_PWM_MAX: remove useless use of min().
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Suggested-by: Uwe Kleine-König <ukleinek@kernel.org>
Link: https://patch.msgid.link/20250924-mdb-max7360-pwm-optimize-v1-1-5959eeed20d8@bootlin.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The function pwm_apply_args() was introduced with the concept of atomic
PWM configuration and needed for drivers not using this concept yet. Now
all drivers are converted accordingly and so no callers are left which
allows to remove this function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20250922094327.1143944-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Instead of caring to correctly pluralize "PWM device(s)" using
(chip->npwm != 1) ? "s" : ""
or
str_plural(chip->npwm)
just simplify the format to not need a plural-s.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20250926165702.321514-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Some devices (such as Smaug) report having MOTION_SENSE_FIFO but do not
support controlling the behaviour of the FIFO interrupt via the
FIFO_INT_ENABLE command and in these cases the interrupt is always
enabled. However, currently the code assumes that if MOTION_SENSE_FIFO
is supported then so is FIFO_INT_ENABLE, and when it tries to enable
the interrupt via this command and an unsupported device reports a
failure it then propagates this into failing the sensors probe.
Interpret the return value -EINVAL as a device where FIFO_INT_ENABLE is
not present and the interrupt is always enabled.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Link: https://lore.kernel.org/r/20251112-diogo-smaug_ec_sensorhub-v1-1-f71d4e9eb9d4@tecnico.ulisboa.pt
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Replace two magic values in ccp_device with
existing constants.
Signed-off-by: Marius Zachmann <mail@mariuszachmann.de>
Link: https://lore.kernel.org/r/20251113100024.11103-3-mail@mariuszachmann.de
[groeck: Updated subject to include subsystem/driver]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add error checking when loading temperature channel label defined
in device tree. Handling of error from of_property_read_string()
is inspired by lm90 driver and therefor contain same error string.
Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Link: https://lore.kernel.org/r/20251111144406.7489-1-bruno.thomsen@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
IEEE 1394 defines the split, concatenated, and unified transaction.
To support the split transaction, core function uses linked list to
maintain the transactions waiting for acknowledge packet. After clearing
sources of hardware interrupts, the acknowledge packet is no longer
handled, therefore it is required to abort the pending transactions.
This commit executes callback with RCODE_CANCELLED for the pending
transactions at card removal.
Link: https://lore.kernel.org/r/20251111223834.311287-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
The default FIFO data width of the Cadence SPI IP is 8 bits, but
the hardware supports configurations of 16 bits and 32 bits.
This patch enhances the driver to support communication with both
16-bits and 32-bits FIFO data widths.
Signed-off-by: Jun Guo <jun.guo@cixtech.com>
Link: https://patch.msgid.link/20251031073003.3289573-3-jun.guo@cixtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
- Add new compatible strings to the DT binding documents to support
cix sky1 SoC.
Signed-off-by: Jun Guo <jun.guo@cixtech.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251031073003.3289573-2-jun.guo@cixtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use devm_clk_get_optional_enabled() helper instead of calling
devm_clk_get_optional() and then clk_prepare_enable().
Assign the result of devm_clk_get_optional_enabled() directly to
pcie->refclk to avoid using a local 'clk' variable.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20251028154229.6774-2-linux.amoon@gmail.com
The 'pci-keystone.c' driver is the application/glue/wrapper driver for the
Designware PCIe Controllers on TI SoCs. Now that all of the helper APIs
that the 'pci-keystone.c' driver depends upon have been exported for use,
enable support to build the driver as a loadable module.
When building the driver as a module, the functions marked by the '__init'
keyword may be invoked after the init memory has been freed by the kernel.
This results will result in an exception of the form:
Unable to handle kernel paging request at virtual address ...
Mem abort info:
...
pc : ks_pcie_host_init+0x0/0x540
lr : dw_pcie_host_init+0x170/0x498
...
ks_pcie_host_init+0x0/0x540 (P)
ks_pcie_probe+0x728/0x84c
platform_probe+0x5c/0x98
really_probe+0xbc/0x29c
__driver_probe_device+0x78/0x12c
driver_probe_device+0xd8/0x15c
To address this, introduce a new function namely 'ks_pcie_init()' to
register the 'fault handler' while removing the '__init' keyword from
existing functions.
Note that hook_fault_code() is defined as '__init' function. Since the init
functions should never be called during runtime (after init memory freeing
stage), the driver is made as a built-in if CONFIG_ARM (where
hook_fault_code() is used) is selected.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
[mani: added a note about hook_fault_code()]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251029080547.1253757-5-s-vadapalli@ti.com
The pci-keystone.c driver uses the functions 'dw_pcie_allocate_domains()'
and 'dw_pcie_ep_raise_msix_irq()'. Export them in preparation for enabling
the pci-keystone.c driver to be built as a loadable module.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251029080547.1253757-3-s-vadapalli@ti.com
The pci-keystone.c driver uses the 'pci_get_host_bridge_device()' helper.
Export it in preparation for enabling the pci-keystone.c driver to be built
as a loadable module.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251029080547.1253757-2-s-vadapalli@ti.com
Commit under Fixes introduced support for PCIe EP mode on AM654x platforms.
When the mode happens to be either "DW_PCIE_RC_TYPE" or "DW_PCIE_EP_TYPE",
the PCIe Controller is configured accordingly. However, when the mode is
neither of them, an error message is displayed, but the driver probe
succeeds. Since this "invalid" mode is not associated with a functional
PCIe Controller, the probe should fail.
Fix the behavior by exiting "ks_pcie_probe()" with the return value of
"-EINVAL" in addition to displaying the existing error message when the
mode is invalid.
Fixes: 23284ad677 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251029080547.1253757-4-s-vadapalli@ti.com
Most PCIe HW returns 0xffffffff for failed reads on PCIe, but by default
Broadcom's STB PCIe controller effects an abort. Some SoCs -- 7216 and its
descendants -- have new HW that identifies error details.
Add a simple handler to print diagnostic info in case the PCIe controller
was the cause of the abort. Unfortunately, an abort still occurs.
Read the error registers only when the PCIe bridge is active and the PCIe
registers are accessible. Otherwise, a "die" event caused by something
other than PCIe could cause an abort if the PCIe "die" handler tried to
access registers when the bridge is off.
Example error output:
brcm-pcie 8b20000.pcie: Error: Mem Acc: 32bit, read, @0x38000000
brcm-pcie 8b20000.pcie: Type: TO=0 Abt=0 UnspReq=1 AccDsble=0 BadAddr=0
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20251029193616.3670003-3-james.quinlan@broadcom.com
In a future commit, a new handler will be introduced that in part does
reads and writes to some of the PCIe registers. When this handler is
invoked, it is paramount that it does not do these register accesses when
the PCIe bridge is inactive, as this will cause CPU abort errors.
To solve this we keep a spinlock that guards a variable which indicates
whether the bridge is on or off. When the bridge is on, access of the PCIe
HW registers may proceed.
Since there are multiple ways to reset the bridge, we introduce a general
function to obtain the spinlock, call the specific function that is used
for the specific SoC, sets the bridge active indicator variable, and
releases the spinlock.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20251029193616.3670003-2-james.quinlan@broadcom.com
TWL603x has also a power button function, so add the corresponding subnode.
As not in all cases there is a power button connected to the corresponding
pad of the TWL603x, the functionality can be disabled by
status = "disabled" or simply not adding the subnode.
To keep things simple, follow the established design pattern of using const
interrupts as used also by the other subdevices.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251106-twl6030-button-v4-1-fdf1aa6e1e9a@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
This patch continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
The old wq (system_wq) will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251105111924.141555-1-marco.crivellari@suse.com
Signed-off-by: Lee Jones <lee@kernel.org>
Commit ebaec90ec0 ("mfd: pf1550: Add core driver for the PF1550 PMIC")
adds the header file pf1550.h in include/linux/mfd/, and commit
a7d6255a0b ("MAINTAINERS: Add an entry for PF1550 MFD driver") adds a new
section NXP PF1550 PMIC MFD DRIVER intending to refer to that header file.
It however adds the entry for pfd1550.h; note the additional letter in the
filename.
Adjust the file entry to refer to the intended file.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Reviewed-by: Samuel Kayode <samkay014@gmail.com>
Link: https://patch.msgid.link/20251029104228.95498-1-lukas.bulwahn@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
Integrate the selftests as part of kunit.
Now instead of the test only being run at boot, it can run:
- With CONFIG_IOMMU_IO_PGTABLE_LPAE_KUNIT_TEST=y
It will automatically run at boot as before.
- Otherwise with CONFIG_IOMMU_IO_PGTABLE_LPAE_KUNIT_TEST=m:
1) on module load:
Once the module load the self test will run
# modprobe io-pgtable-arm-selftests
2) debugfs
With CONFIG_KUNIT_DEBUGFS=y You can run the test with
# echo 1 > /sys/kernel/debug/kunit/io-pgtable-arm-test/run
3) Using kunit.py
You can also use the helper script which uses Qemu in the background
# ./tools/testing/kunit/kunit.py run --build_dir build_kunit_arm64 --arch arm64 \
--make_options LLVM=1 --kunitconfig ./kunit/kunitconfig
[18:01:09] ============= io-pgtable-arm-test (1 subtest) ==============
[18:01:09] [PASSED] arm_lpae_do_selftests
[18:01:09] =============== [PASSED] io-pgtable-arm-test ===============
[18:01:09] ============================================================
Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Remove the __init constraint, as the test will be converted to KUnit,
it can run on-demand after later.
Also, as KUnit can be a module, make this test modular.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Clean up the io-pgtable-arm library by moving the selftests out.
Next the tests will be registered with kunit.
This is useful also to factor out kernel specific code out, so
it can compiled as part of the hypervisor object.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
At the moment, if the selftest fails it prints a lot of information
about the page table (size, levels...) this requires access to many
internals, which has to be exposed in the next patch moving the
tests out.
Instead, we can simplify the print to only print the fmt and
for each test ias, oas and pgsize_bitmap are already printed.
That is enough to identify the failed case, and the rest can
be deduced from the code.
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Replace sprintf() with sysfs_emit() in sysfs show functions.
sysfs_emit() is preferred to format sysfs output as it provides better
bounds checking. No functional changes.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20251103120809.32834-1-thorsten.blum@linux.dev
Signed-off-by: Lee Jones <lee@kernel.org>
Current IOMMU driver prints "Completion-wait Time-out" error message with
insufficient information to further debug the issue.
Enhancing the error message as following:
1. Log IOMMU PCI device ID in the error message.
2. With "amd_iommu_dump=1" kernel command line option, dump entire
command buffer entries including Head and Tail offset.
Dump the entire command buffer only on the first 'Completion-wait Time-out'
to avoid dmesg spam.
Signed-off-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Reviewed-by: Ankit Soni <Ankit.Soni@amd.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Document the compatible string for the PM7550 PMIC.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://patch.msgid.link/20251023-sm7635-pmxr2230-v3-2-f70466c030fe@fairphone.com
Signed-off-by: Lee Jones <lee@kernel.org>
Document compatible for PM7550 Torch and Flash LED controller.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://patch.msgid.link/20251023-sm7635-pmxr2230-v3-1-f70466c030fe@fairphone.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add the PMIV0104 PMIC which is found on e.g. boards with Milos SoCs.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://patch.msgid.link/20251023-sm7635-pmiv0104-v3-1-27f1c417376d@fairphone.com
Signed-off-by: Lee Jones <lee@kernel.org>
These days we can register syscons with of_syscon_register_regmap() so
when we can't find the syscon that probably means it hasn't been
registered yet. Return -EPROBE_DEFER so the driver will try probing
again.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/aQdHmrchkmOr34r3@stanley.mountain
Signed-off-by: Lee Jones <lee@kernel.org>
The function netxbig_gpio_ext_get() acquires GPIO descriptors but
fails to release them when errors occur mid-way through initialization.
The cleanup callback registered by devm_add_action_or_reset() only
runs on success, leaving acquired GPIOs leaked on error paths.
Add goto-based error handling to release all acquired GPIOs before
returning errors.
Fixes: 9af512e819 ("leds: netxbig: Convert to use GPIO descriptors")
Suggested-by: Markus Elfring <Markus.Elfring@web.de>
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20251031021620.781-1-vulab@iscas.ac.cn
Signed-off-by: Lee Jones <lee@kernel.org>
When a process exits with numerous large, pinned memory regions consisting
of 4KB pages, the cleanup of the memory region through __ib_umem_release()
may cause soft lockups. This is because unpin_user_page_range_dirty_lock()
is called in a tight loop for unpin and releasing page without yielding the
CPU.
watchdog: BUG: soft lockup - CPU#44 stuck for 26s! [python3:73464]
Kernel panic - not syncing: softlockup: hung tasks
CPU: 44 PID: 73464 Comm: python3 Tainted: G OEL
asm_sysvec_apic_timer_interrupt+0x1b/0x20
RIP: 0010:free_unref_page+0xff/0x190
? free_unref_page+0xe3/0x190
__put_page+0x77/0xe0
put_compound_head+0xed/0x100
unpin_user_page_range_dirty_lock+0xb2/0x180
__ib_umem_release+0x57/0xb0 [ib_core]
ib_umem_release+0x3f/0xd0 [ib_core]
mlx5_ib_dereg_mr+0x2e9/0x440 [mlx5_ib]
ib_dereg_mr_user+0x43/0xb0 [ib_core]
uverbs_free_mr+0x15/0x20 [ib_uverbs]
destroy_hw_idr_uobject+0x21/0x60 [ib_uverbs]
uverbs_destroy_uobject+0x38/0x1b0 [ib_uverbs]
__uverbs_cleanup_ufile+0xd1/0x150 [ib_uverbs]
uverbs_destroy_ufile_hw+0x3f/0x100 [ib_uverbs]
ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
__fput+0x9c/0x280
____fput+0xe/0x20
task_work_run+0x6a/0xb0
do_exit+0x217/0x3c0
do_group_exit+0x3b/0xb0
get_signal+0x150/0x900
arch_do_signal_or_restart+0xde/0x100
exit_to_user_mode_loop+0xc4/0x160
exit_to_user_mode_prepare+0xa0/0xb0
syscall_exit_to_user_mode+0x27/0x50
do_syscall_64+0x63/0xb0
Fix soft lockup issues by incorporating cond_resched() calls within
__ib_umem_release(), and this SG entries are typically grouped in 2MB
chunks on x86_64, adding cond_resched() should has minimal performance
impact.
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Link: https://patch.msgid.link/20251113095317.2628-1-lirongqing@baidu.com
Acked-by: Junxian Huang <huangjunxian6@hisilicon.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
If a GPIO is used to control the chip's enable pin, it needs to be pulled
high before any i2c communication is attempted.
Currently, the enable GPIO handling is not correct.
Assume the enable GPIO is low when the probe function is entered. In this
case the device is in SHUTDOWN mode and does not react to i2c commands.
During probe the following sequence happens:
1. The call to lp50xx_reset() on line 548 has no effect as i2c is not
possible yet.
2. Then - on line 552 - lp50xx_enable_disable() is called. As
"priv->enable_gpio“ has not yet been initialized, setting the GPIO has
no effect. Also the i2c enable command is not executed as the device
is still in SHUTDOWN.
3. On line 556 the call to lp50xx_probe_dt() finally parses the rest of
the DT and the configured priv->enable_gpio is set up.
As a result the device is still in SHUTDOWN mode and not ready for
operation.
Split lp50xx_enable_disable() into distinct enable and disable functions
to enforce correct ordering between enable_gpio manipulations and i2c
commands.
Read enable_gpio configuration from DT before attempting to manipulate
enable_gpio.
Add delays to observe correct wait timing after manipulating enable_gpio
and before any i2c communication.
Cc: stable@vger.kernel.org
Fixes: 242b81170f ("leds: lp50xx: Add the LP50XX family of the RGB LED driver")
Signed-off-by: Christian Hitz <christian.hitz@bbv.ch>
Link: https://patch.msgid.link/20251028155141.1603193-1-christian@klarinett.li
Signed-off-by: Lee Jones <lee@kernel.org>
The `pwm_th1520` Rust driver calls C functions from the `PWM` namespace,
triggering `modpost` warnings due to missing namespace import
declarations in its `.modinfo` section.
Fix these warnings and simplify the module declaration by switching from
the generic `kernel::module_platform_driver!` macro to the newly
introduced PWM-specific `kernel::module_pwm_platform_driver!` macro.
The new macro automatically handles the required `imports_ns: ["PWM"]`
declaration.
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev>
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Link: https://patch.msgid.link/20251028-pwm_fixes-v1-3-25a532d31998@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Clippy warns about redundant struct field initialization when the field
name and the variable name are the same (e.g., `status: status`).
No functional change.
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Link: https://patch.msgid.link/20251028-pwm_fixes-v1-4-25a532d31998@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Add the Device Tree binding documentation for the T-HEAD
TH1520 SoC PWM controller.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Drew Fustini <fustini@kernel.org>
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Link: https://patch.msgid.link/20251016-rust-next-pwm-working-fan-for-sending-v16-5-a5df2405d2bd@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Introduce a PWM driver for the T-HEAD TH1520 SoC, written in Rust and
utilizing the safe PWM abstractions from the preceding commit.
The driver implements the pwm::PwmOps trait using the modern waveform
API (round_waveform_tohw, write_waveform, etc.) to support configuration
of period, duty cycle, and polarity for the TH1520's PWM channels.
Resource management is handled using idiomatic Rust patterns. The PWM
chip object is allocated via pwm::Chip::new and its registration with
the PWM core is managed by the pwm::Registration RAII guard. This
ensures pwmchip_remove is always called when the driver unbinds,
preventing resource leaks. Device managed resources are used for the
MMIO region, and the clock lifecycle is correctly managed in the
driver's private data Drop implementation.
The driver's core logic is written entirely in safe Rust, with no unsafe
blocks, except for the Send and Sync implementations for the driver
data, which are explained in the comments.
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Link: https://patch.msgid.link/20251016-rust-next-pwm-working-fan-for-sending-v16-4-a5df2405d2bd@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
`rustdoc` reports a broken intra-doc link:
error: unresolved link to `Devres::register`
--> rust/kernel/pwm.rs:722:11
|
722 | /// via [`Devres::register`]. This ties the lifetime of the PWM chip registration
| ^^^^^^^^^^^^^^^^ no item named `Devres` in scope
|
= note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(rustdoc::broken_intra_doc_links)]`
Thus fix it.
Fixes: d8046cd508 ("rust: pwm: Add complete abstraction layer")
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://patch.msgid.link/20251029181940.780629-1-ojeda@kernel.org
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
We have a Switch Upstream Port (2b:00.0) that has a PTM Capability, but
doesn't advertise support for any PTM roles:
Capabilities: [220 v1] Precision Time Measurement
PTMCap: Requester- Responder- Root-
Linux enables PTM without looking into what roles it actually supports, and
apparently the Port immediately sends PTM Requests even though it doesn't
support the PTM Requester role. The messages include an invalid bus number,
so the Root Port detects an ACS Violation (see the PCIe r7.0, sec 6.12.1.1,
implementation note):
pci 0000:2b:00.0: [8086:5786] type 01 class 0x060400 PCIe Switch Upstream Port
pci 0000:2b:00.0: PTM enabled, 4ns granularity
pcieport 0000:00:07.1: AER: Multiple Uncorrectable (Non-Fatal) error message received from 0000:00:07.1
pcieport 0000:00:07.1: PCIe Bus Error: severity=Uncorrectable (Non-Fatal), type=Transaction Layer, (Receiver ID)
pcieport 0000:00:07.1: device [8086:e44f] error status/mask=00200000/00000000
pcieport 0000:00:07.1: [21] ACSViol (First)
pcieport 0000:00:07.1: AER: TLP Header: 0x34000000 0x00000052 0x00000000 0x00000000
The TLP Header shows a 4 DW header, no data (001b) Msg with Local routing
(1 0100b) with Requester ID 0x0000 and PTM Request code (0x52).
Fix this by enabling PTM only if the following conditions are true (see sec
6.21.1 figure 6-21):
- Endpoint must advertise PTM Requester Capable
- Switch Upstream Port must advertise PTM Responder Capable
- Root Port must advertise PTM Root Capable
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: commit log, comments]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251112074614.1440266-1-mika.westerberg@linux.intel.com
Remove the duplicate code and change info to a pointer. caps are not used.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/21-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Remove the duplicate code and change info to a pointer. caps are not used.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Since the core function signature changes it has to flow up to all
drivers.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Brett Creeley <brett.creeley@amd.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/19-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
This driver open codes the cap chain manipulations. Instead use
vfio_info_add_capability() and the get_region_info_caps() op.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/16-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
This op does the copy to/from user for the info and can return back
a cap chain through a vfio_info_cap * result.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/15-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Remove the fallback through the ioctl callback, no drivers use this now.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/14-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Change the signature of vfio_cdx_ioctl_get_region_info() and hook it to
the op.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/11-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Move it out of vfio_platform_ioctl() and re-indent it. Add it to all
platform drivers.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/9-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Now that every variant driver provides a get_region_info op remove the
ioctl based dispatch from vfio_pci_core_ioctl().
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/5-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Remove virtiovf_vfio_pci_core_ioctl() and change the signature of
virtiovf_pci_ioctl_get_region_info().
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/3-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Change the function signature of hisi_acc_vfio_pci_ioctl()
and re-indent it.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/2-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Instead of hooking the general ioctl op, have the core code directly
decode VFIO_DEVICE_GET_REGION_INFO and call an op just for it.
This is intended to allow mechanical changes to the drivers to pull their
VFIO_DEVICE_GET_REGION_INFO int oa function. Later patches will improve
the function signature to consolidate more code.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/1-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
With the current code flow, once the generic target is updated
target->registered is set and the remaining code is skipped.
So return immediately instead of going through the checks and
then skip.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20251105235115.85062-2-dave.jiang@intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
When a decoder is locked, it means that its configuration cannot be
changed. CXL spec r3.2 8.2.4.20.13 discusses the details regarding
locked decoders. Locking happens when bit 8 of the decoder control
register is set and then the decoder is committed afterwards (CXL
spec r3.2 8.2.4.20.7).
Given that the driver creates a virtual decoder for each CFMWS, the
Fixed Device Configuration (bit 4) of the Window Restriction field is
considered as locking for the virtual decoder by the driver.
The current driver code disregards the locked status and a region can
be destroyed regardless of the locking state.
Add a region flag to indicate the region is in a locked configuration.
The driver will considered a region locked if the CFMWS or any decoder
is configured as locked. The consideration is all or nothing regarding
the locked state. It is reasonable to determine the region "locked"
status while the region is being assembled based on the decoders.
Add a check in region commit_store() to intercept when a 0 is written
to the commit sysfs attribute in order to prevent the destruction of a
region when in locked state. This should be the only entry point from user
space to destroy a region.
Add a check is added to cxl_decoder_reset() to prevent resetting a locked
decoder within the kernel driver.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20251105201826.2901915-1-dave.jiang@intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
The RAA229141A is a digital dual output multiphase (X+Y ≤ 12) PWM
controller designed to be compliant with Intel VR13, VR13.HC, VR14 and
VR14.Cloud specifications, targeting VCORE and auxiliary rails.
The RAA229141A supports the Intel SVID interface along with PMBus V1.3
specifications, making it ideal for controlling the microprocessor core and
system rails in Intel VR13, VR13.HC, VR14 and VR14.Cloud platforms.
Signed-off-by: Jeff Lin <jefflin994697@gmail.com>
Link: https://lore.kernel.org/r/20251106104519.2014853-1-jefflin994697@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add a driver for the ST Microelectronics TSC1641 16-bit high-precision
power monitor. The driver supports reading bus voltage, current, power,
and temperature. Sysfs attributes are exposed for shunt resistor and
update interval. The driver integrates with the hwmon subsystem and
supports optional ALERT pin polarity configuration.
Signed-off-by: Igor Reznichenko <igor@reznichenko.net>
Link: https://lore.kernel.org/r/20251105201406.1210856-3-igor@reznichenko.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add binding for the TSC1641 I2C power monitor.
Signed-off-by: Igor Reznichenko <igor@reznichenko.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20251105201406.1210856-2-igor@reznichenko.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Convert the Nuvoton NPCM PSPI binding to DT schema format.
Also update the binding to fix shortcoming:
* Drop clock-frequency property: it is never read in the NPCM PSPI
driver and has no effect.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251112150950.1680154-1-tmaimon77@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds the WQ_UNBOUND flag to explicitly request
alloc_workqueue() to be unbound, because this specific workload has no
benefit being per-cpu.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://lore.kernel.org/r/20251112120125.124578-1-marco.crivellari@suse.com
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
The variable udata cannot be NULL because irdma_create_user_ah() always
receives it. Therefore, the if() check can be safely removed.
Signed-off-by: Tuo Li <islituo@gmail.com>
Link: https://patch.msgid.link/20251112120253.68945-1-islituo@gmail.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Per design recommendations, the memory clock can be gated when there
is no in-flight transfer, which helps save power. This feature is
introduced alongside internal phase support, and this patch enables it.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In include/rdma/ib_cm.h:
Correct a typedef's kernel-doc notation by adding the 'typedef' keyword
to it to avoid a warning.
Add a leading " *" to a kernel-doc line to avoid a warning.
Warning: ib_cm.h:289 function parameter 'ib_cm_handler' not described
in 'int'
Warning: ib_cm.h:289 expecting prototype for ib_cm_handler(). Prototype
was for int() instead
Warning: ib_cm.h:484 bad line: connection message in case duplicates
are received.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20251112062908.2711007-1-rdunlap@infradead.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Single patch to expose new link mode for 1600Gbps, utilizing 8 lanes at
200Gbps per lane.
Signed-off-by: Leon Romanovsky <leon@kernel.org>
* mlx5-next:
net/mlx5: Expose definition for 1600Gbps link mode
The efi_memattr_init() function's return values (0 and -ENOMEM) are never
checked by callers. Convert the function to return void since the return
status is unused.
Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Add a beginning " *" to each line to avoid kernel-doc warnings:
Warning: drivers/firmware/efi/stmm/mm_communication.h:34 bad line:
Warning: drivers/firmware/efi/stmm/mm_communication.h:113 bad line:
Warning: drivers/firmware/efi/stmm/mm_communication.h:130 bad line:
Fixes: c44b6be62e ("efi: Add tee-based EFI variable driver")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
In the efi_create_mapping() in arch/riscv/kernel/efi.c,
the return value is always 0, and this debug message
is unnecessary. So, remove it.
Signed-off-by: Qiang Ma <maqianga@uniontech.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Merge the mmc fixes for v6.18-rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.19.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
This patch continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
Replace system_wq with system_percpu_wq, keeping the same old behavior.
The old wq (system_wq) will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This adds CQE support for the Rockchip RK3588 and RK3576 platform. To
be functional, the eMMC device-tree node must have a 'supports-cqe;'
flag property.
As the RK3576 device-tree has been upstreamed with the 'supports-cqe;'
property set by default, the kernel already tried to use CQE, which
results in system hang during suspend. This fixes the issue.
Co-developed-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Signed-off-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add support for the mmc controller in the Eswin EIC7700 with the new
compatible "eswin,eic7700-dwcmshc". Implement custom sdhci_ops for
set_clock, reset, set_uhs_signaling, platform_execute_tuning.
Signed-off-by: Huan He <hehuan1@eswincomputing.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
EIC7700 use Synopsys dwcmshc IP for SD/eMMC controllers.
Add Eswin EIC7700 support in sdhci-of-dwcmshc.yaml.
Signed-off-by: Huan He <hehuan1@eswincomputing.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
S25FS-S family supports SMPT that helps to detect sector layout settings
in configuration registers, but some of parameters in the table are
wrong or undetermined so the fixups below are required.
Read Any Register op is used to read configuration registers that
related to sector map. The op requires 8 cycles latency by default.
Implement smpt_read_dummy() to set correct dummy cycles.
Map ID is structured by combination of CR3NV[3], CR1NV[2], and CR3NV[1].
However, in S25FS512S, CR3NV[1] is RFU and always 0, while map IDs
defined in the table assume it is always 1. Implement smpt_map_id() to
fix map ID for S25FS512S. Other densities in S25FS-S family (256Mb and
128Mb) don't need this fix as CR3NV[1] in those chips is configurable
and map IDs are correctly defined in SMPT.
Co-developed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # S25FS512S
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Certain chips have inconsistent Sector Map Parameter Table (SMPT) data,
which leads to the wrong map ID being identified, causing failures to
detect the correct sector map.
To fix this, introduce smpt_map_id() into the struct spi_nor_fixups.
This function will be called after the initial SMPT-based detection,
allowing chip-specific logic to correct the map ID.
Infineon S25FS512S needs this fixup as it has inconsistency between map
ID definition and configuration register value actually obtained.
Co-developed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # S25FS512S
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
SMPT contains config detection info that describes opcode, address, and
dummy cycles to read sector map config. The dummy cycles parameter can
be SMPT_CMD_READ_DUMMY_IS_VARIABLE and in that case nor->read_dummy
(initialized as 0) is used. In Infineon flash chips, Read Any Register
command with variable dummy cycle is defined in SMPT. S25Hx/S28Hx flash
has 0 dummy cycle by default to read volatile regiters and
nor->read_dummy can work. S25FS-S flash has 8 dummy cycles so we need a
hook that can fix dummy cycles with actually used value.
Inroduce smpt_read_dummy() in struct spi_nor_fixups. It is called when
the dummy cycle field in SMPT config detection is 'varialble'.
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # S25FS512S
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
After device_initialize() is called, use put_device() to release the
device according to kernel device management rules. While direct
kfree() work in this case, using put_device() is more correct.
Found by code review.
Fixes: 9cb8374804 ("RDMA/rtrs: server: main functionality")
Signed-off-by: Ma Ke <make24@iscas.ac.cn>
Link: https://patch.msgid.link/20251110005158.13394-1-make24@iscas.ac.cn
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
First of all, the driver was parsing the 'dbi' register region as 'elbi'.
This was due to DT mistakenly passing 'dbi' as 'elbi'. Since the DT is
now fixed to supply 'dbi' region, this driver can rely on the DWC core
driver to parse and map it.
However, to support the old DTs, if the 'elbi' region is found in DT, parse
and map the region as both 'dw_pcie::elbi_base' as 'dw_pcie::dbi_base'.
This will allow the driver to work with both broken and fixed DTs.
Also, skip parsing the 'elbi' region in DWC core if 'pci->elbi_base' was
already populated.
Fixes: 9c0ef6d34f ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver")
Fixes: c96992a24b ("PCI: dwc: Add support for ELBI resource mapping")
Reported-by: Linnaea Lavia <linnaea-von-lavia@live.com>
Closes: https://lore.kernel.org/linux-pci/DM4PR05MB102707B8CDF84D776C39F22F2C7F0A@DM4PR05MB10270.namprd05.prod.outlook.com/
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Bananapi-M2S
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Cc: stable@vger.kernel.org # 6.2
Link: https://patch.msgid.link/20251101-pci-meson-fix-v1-3-c50dcc56ed6a@oss.qualcomm.com
Binding incorrectly specifies the 'DBI' region as 'ELBI'. DBI is a must
have region for DWC controllers as it has the Root Port and controller
specific registers, while ELBI has optional registers.
Hence, fix the binding. Though this is an ABI break, this change is needed
to accurately describe the PCI memory map.
Fixes: 7cd2103911 ("dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251101-pci-meson-fix-v1-1-c50dcc56ed6a@oss.qualcomm.com
After unbinding the driver, another kthread `cros_ec_console_log_work`
is still accessing the device, resulting an UAF and crash.
The driver doesn't unregister the EC device in .remove() which should
shutdown sub-devices synchronously. Fix it.
Fixes: 26a14267af ("platform/chrome: Add ChromeOS EC ISHTP driver")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20251031033900.3577394-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251107133626.190952-1-marco.crivellari@suse.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251107133306.187939-1-marco.crivellari@suse.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
The CQ registry was never actually used (ceq->reg_cq was always NULL),
so remove the dead code.
Signed-off-by: Jacob Moroni <jmoroni@google.com>
Link: https://patch.msgid.link/20251105162841.31786-1-jmoroni@google.com
Acked-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Allows the creation of RDMA TRANSPORT tables over VFs/SFs that
belong to another eswitch manager. Which is only possible for PFs that
were connected via a create_lag PRM command.
Signed-off-by: Patrisious Haddad <phaddad@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20251029-support-other-eswitch-v1-7-98bb707b5d57@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Refactor the _get_prio() function to remove redundant arguments by
reusing the existing flow table attributes struct instead of passing
attributes separately. This improves code clarity and maintainability.
In addition allows downstream patch to add new parameter without
needing to change __get_prio() arguments.
Signed-off-by: Patrisious Haddad <phaddad@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20251029-support-other-eswitch-v1-6-98bb707b5d57@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
When building a devx object destruction command for steering objects add
consideration for other_eswitch argument to allow proper destruction for
objects that were created with it.
Signed-off-by: Patrisious Haddad <phaddad@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20251029-support-other-eswitch-v1-5-98bb707b5d57@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
In case of a LAG configuration change the root namespace core device for
all of the LAG slaves to be the core device of the master device for
RDMA_TRANSPORT namespaces, in order to ensure all tables are created
through the master device.
Once the LAG is disabled revert back to the native core device.
Signed-off-by: Patrisious Haddad <phaddad@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20251029-support-other-eswitch-v1-4-98bb707b5d57@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
When the device in switchdev mode, the RDMA device manages all the
vports which belong to its representors, which can lead to a situation
where the PF that is used to manage the RDMA device isn't the native PF
of some of the vports it manages.
Add infrastructure to allow the master PF to manage all the hardware
resources for the vports under its management.
Whereas currently the only such resource is RDMA TRANSPORT steering
domains.
That is done by adding new FW argument other_eswitch which is passed by
the driver to the FW to allow the master PF to properly manage vports
belonging to other native PF.
Signed-off-by: Leon Romanovsky <leon@kernel.org>
This patch adds debugfs interfaces that allows the user to
enable/disable the RoCE CQ coalescing and fine tune certain
CQ coalescing parameters which would be helpful during debug.
Signed-off-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com>
Reviewed-by: Hongguang Gao <hongguang.gao@broadcom.com>
Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Link: https://patch.msgid.link/20251103043425.234846-1-kalesh-anakkur.purayil@broadcom.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Due to the factors external to the system, hardware events may still be
handled while a card instance is being removed. The sources of hardware
IRQs should be cleared during card removal so that workqueues can be safely
destroyed.
This commit adds a disable callback to the underlying driver operations.
After this callback returns, the underlying driver guarantees that it
will no longer handle hardware events.
Link: https://lore.kernel.org/r/20251109065525.163464-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
For 'always-on' and 'boot-on' regulators, the set_machine_constraints()
may enable supply before enabling the main regulator, however if the
latter fails, the function returns with an error but the supply remains
enabled.
When this happens, the regulator_register() function continues on the
error path where it puts the supply regulator. Since enabling the supply
is not balanced with a disable call, a warning similar to the following
gets issued from _regulator_put():
[ 1.603889] WARNING: CPU: 2 PID: 44 at _regulator_put+0x8c/0xa0
[ 1.603908] Modules linked in:
[ 1.603926] CPU: 2 UID: 0 PID: 44 Comm: kworker/u16:3 Not tainted 6.18.0-rc4 #0 NONE
[ 1.603938] Hardware name: Qualcomm Technologies, Inc. IPQ9574/AP-AL02-C7 (DT)
[ 1.603945] Workqueue: async async_run_entry_fn
[ 1.603958] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.603967] pc : _regulator_put+0x8c/0xa0
[ 1.603976] lr : _regulator_put+0x7c/0xa0
...
[ 1.604140] Call trace:
[ 1.604145] _regulator_put+0x8c/0xa0 (P)
[ 1.604156] regulator_register+0x2ec/0xbf0
[ 1.604166] devm_regulator_register+0x60/0xb0
[ 1.604178] rpm_reg_probe+0x120/0x208
[ 1.604187] platform_probe+0x64/0xa8
...
In order to avoid this, change the set_machine_constraints() function to
disable the supply if enabling the main regulator fails.
Fixes: 05f224ca66 ("regulator: core: Clean enabling always-on regulators + their supplies")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://patch.msgid.link/20251107-regulator-disable-supply-v1-1-c95f0536f1b5@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Some adjustments pointed out by Randy:
"decodes an full 64-bit" -> "decodes the full 64 bit"
Correct the function parameter name for iova_to_phys()
Use the recommended section heading style.
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Fixes: ab0b572847 ("genpt: Add Documentation/ files")
Fixes: 879ced2bab ("iommupt: Add the AMD IOMMU v1 page table format")
Fixes: 9d4c274cd7 ("iommupt: Add iova_to_phys op")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Sphinx reports kernel-doc warnings when making htmldocs:
WARNING: ./drivers/iommu/generic_pt/pt_common.h:361 function parameter 'bitnr' not described in 'pt_test_sw_bit_acquire'
WARNING: ./drivers/iommu/generic_pt/pt_common.h:371 function parameter 'bitnr' not described in 'pt_set_sw_bit_release'
Describe @bitnr to squash them.
Fixes: bcc64b57b4 ("iommupt: Add basic support for SW bits in the page table")
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Stephen Rothwell reports htmldocs warning when merging iommu tree:
Documentation/driver-api/generic_pt.rst:32: WARNING: Literal block expected; none found. [docutils]
This is because of duplicate double colon code block markers: one after
generic_pt/fmt/iommu_amdv1.c and the one in its preceding paragraph. The
resulting htmldocs, however, only marks the include listing (after the
former) up as it should be.
Drop the latter to fix the warning.
Fixes: ab0b572847 ("genpt: Add Documentation/ files")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/linux-next/20251106143925.578e411b@canb.auug.org.au/
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the
semantic patch at scripts/coccinelle/misc/semicolon.cocci.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20251107085109.2316999-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
This continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This specific workload do not benefit from a per-cpu workqueue, so use
the default unbound workqueue (system_dfl_wq) instead.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251106142914.227875-1-marco.crivellari@suse.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Alex Elder <elder@riscstar.com>:
This series adds support for the SpacemiT K1 SoC QSPI. This IP is
generally compatible with the Freescale QSPI driver, requiring three
minor changes to enable it to be supported. The changes are:
- Adding support for optional resets
- Having the clock *not* be disabled when changing its rate
- Allowing the size of storage blocks written to flash chips
to be set to something different from the AHB buffer size
These were introduced and used in an earlier revision of the patch that
became commit fb3957af9ec6 ("pwm: Add Rust driver for T-HEAD TH1520
SoC"). The variant that was actually applied sticks to the modern
waveform abstraction only (and other drivers are supposed to do that,
too), so they can be dropped.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20251025122359.361372-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Rust PWM drivers using the abstractions in `kernel/pwm.rs` typically
call C functions (like `pwmchip_alloc`, `__pwmchip_add`, etc.) that are
exported to the `PWM` C symbol namespace.
With the introduction of `imports_ns` support in the `module!` macro,
every PWM driver would need to manually include `imports_ns: ["PWM"]` in
its module declaration.
To simplify this for driver authors and ensure consistency, introduce a
new helper macro `module_pwm_platform_driver!` in `pwm.rs`. This macro
wraps the standard `module_platform_driver!`, forwards all user provided
arguments using the `($($user_args:tt)*)` pattern, and automatically
injects the `imports_ns: ["PWM"]` declaration.
This follows the pattern used in other subsystems (e.g.,
`module_pci_driver!`) to provide specialized module registration
helpers. It makes writing PWM drivers slightly simpler and less error
prone regarding namespace imports.
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Link: https://patch.msgid.link/20251028-pwm_fixes-v1-2-25a532d31998@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Introduce a comprehensive abstraction layer for the PWM subsystem to
enable writing drivers in Rust.
Because `Device`, `Chip`, and `PwmOps` all refer to each other, they
form a single, indivisible unit with circular dependencies. They are
introduced together in this single commit to create a complete,
compilable abstraction layer.
The main components are:
- Data Wrappers: Safe, idiomatic wrappers for core C types like
`pwm_device`, and `pwm_chip`.
- PwmOps Trait: An interface that drivers can implement to provide
their hardware-specific logic, mirroring the C `pwm_ops` interface.
- FFI VTable and Adapter: A bridge to connect the high-level PwmOps trait
to the C kernel's pwm_ops vtable.
- Allocation and Lifetime Management: A high-level `Chip::new()`
API to safely allocate a chip and a `Registration` guard that integrates
with `devres` to manage the chip's registration with the PWM core.
An `AlwaysRefCounted` implementation and a custom release handler
prevent memory leaks by managing the chip's lifetime and freeing
driver data correctly.
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Link: https://patch.msgid.link/20251016-rust-next-pwm-working-fan-for-sending-v16-3-a5df2405d2bd@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Introduce the foundational support for PWM abstractions in Rust.
This commit adds the `RUST_PWM_ABSTRACTIONS` Kconfig option to enable
the feature, along with the necessary build-system support and C
helpers.
It also introduces the first set of safe wrappers for the PWM
subsystem, covering the basic data carrying C structs and enums:
- `Polarity`: A safe wrapper for `enum pwm_polarity`.
- `Waveform`: A wrapper for `struct pwm_waveform`.
- `State`: A wrapper for `struct pwm_state`.
These types provide memory safe, idiomatic Rust representations of the
core PWM data structures and form the building blocks for the
abstractions that will follow.
Tested-by: Drew Fustini <fustini@kernel.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Link: https://patch.msgid.link/20251016-rust-next-pwm-working-fan-for-sending-v16-2-a5df2405d2bd@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The upcoming Rust abstraction layer for the PWM subsystem uses a custom
`dev->release` handler to safely manage the lifetime of its driver
data.
To prevent leaking the memory of the `struct pwm_chip` (allocated by
`pwmchip_alloc`), this custom handler must also call the original
`pwmchip_release` function to complete the cleanup.
Make `pwmchip_release` a global, exported function so that it can be
called from the Rust FFI bridge. This involves removing the `static`
keyword, adding a prototype to the public header, and exporting the
symbol.
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Link: https://patch.msgid.link/20251016-rust-next-pwm-working-fan-for-sending-v16-1-a5df2405d2bd@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Kernel modules that use C symbols exported via `EXPORT_SYMBOL_NS` must
declare this dependency for `modpost` verification. C modules achieve
this by using the `MODULE_IMPORT_NS(NAMESPACE)` macro, which embeds an
`import_ns=<NAMESPACE>` tag into the `.modinfo` section.
The Rust `module!` macro lacked the ability to generate these tags,
resulting in build warnings for Rust drivers (like the PWM driver) that
call namespaced C functions.
Modify the `module!` macro's internal parser (`ModuleInfo`) to accept a
new optional field `imports_ns`, which takes an array of namespace
strings. Update the code generator (`ModInfoBuilder::emit`) loop to
iterate over these strings and emit the corresponding
`import_ns=<NAMESPACE>` tags into the `.modinfo` section using the
existing `#[link_section]` mechanism.
This provides the necessary infrastructure for Rust modules to correctly
declare their C namespace dependencies.
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Acked-by: Daniel Gomez <da.gomez@samsung.com>
Link: https://patch.msgid.link/20251028-pwm_fixes-v1-1-25a532d31998@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
ECSPI in i.MX51 and i.MX53 support target mode. Current code only support
i.MX53. Remove is_imx53_ecspi() check for target mode to support i.MX51.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Link: https://patch.msgid.link/20251027110256.543314-1-carlos.song@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some Apple EFI firmwares do not provide the SMBIOS Protocol,
causing efi_get_smbios_record() to fail. This prevents retrieval of
system information such as product name, which is needed by
apple_set_os() to enable the integrated GPU on dual-graphics Intel
MacBooks.
Add a fallback that directly parses the SMBIOS entry point table when
the protocol is unavailable.
Signed-off-by: Francesco Pompo <francescopompo2@gmail.com>
[ardb: cosmetic tweaks]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The commit, <86624ba3b522> ("vfio/pci: Do vf_token checks for
VFIO_DEVICE_BIND_IOMMUFD") accidentally ignored including the
.match_token_uuid callback in the hisi_acc_vfio_pci_migrn_ops struct.
Introduce the missed callback here.
Fixes: 86624ba3b5 ("vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD")
Cc: stable@vger.kernel.org
Suggested-by: Longfang Liu <liulongfang@huawei.com>
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Longfang Liu <liulongfang@huawei.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20251031170603.2260022-3-rananta@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
For the cases where user includes a non-zero value in 'token_uuid_ptr'
field of 'struct vfio_device_bind_iommufd', the copy_struct_from_user()
in vfio_df_ioctl_bind_iommufd() fails with -E2BIG. For the 'minsz' passed,
copy_struct_from_user() expects the newly introduced field to be zero-ed,
which would be incorrect in this case.
Fix this by passing the actual size of the kernel struct. If working
with a newer userspace, copy_struct_from_user() would copy the
'token_uuid_ptr' field, and if working with an old userspace, it would
zero out this field, thus still retaining backward compatibility.
Fixes: 86624ba3b5 ("vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD")
Cc: stable@vger.kernel.org
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20251031170603.2260022-2-rananta@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
The BCM2712 SoC has PM block but lacks the "asb" and "rpivid_asb"
register spaces, and doesn't need clock(s). Add a compatible
string for bcm2712 to allow probe of bcm2835-wdt and
bcm2835-power drivers.
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20250917063233.1270-4-svarbanov@suse.de
Signed-off-by: Lee Jones <lee@kernel.org>
Allow the SPI_FSL_QUADSPI Kconfig option to be selected if ARCH_SPACEMIT
enabled.
Add support for the SpacemiT K1 SoC in the Freescale QSPI driver by
defining the device type data for its QSPI implementation.
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20251027133008.360237-8-elder@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In fsl_qspi_default_setup(), four registers define the size of blocks of
data to written to each of four chips that comprise SPI NOR flash storage.
They are currently defined to be the same as the AHB buffer size.
The SpacemiT QSPI has an AHB buffer size of 512 bytes, but requires these
four sizes to be multiples of 1024 bytes.
Define a new field sfa_size in the fsl_qspi_devtype_data structure that, if
non-zero, will be used instead of the AHB buffer size to define the size of
these chip regions.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20251027133008.360237-7-elder@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SpacemiT K1 SoC QSPI implementation needs to avoid shutting off the
clock when changing its rate. Add a new quirk to indicate that disabling
and enabling the clock should be skipped when changing its rate.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20251027133008.360237-6-elder@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Change all the needs_*() functions so they are no longer inline, and return
bool rather than int.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20251027133008.360237-5-elder@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for one or more optional exclusive resets. These simply need
to be deasserted at probe time, and can remain that way for the life of the
device.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20251027133008.360237-4-elder@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Allow two resets to be defined to support the SpacemiT K1 SoC QSPI IP.
Move the allOf block down, below the required section.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20251027133008.360237-3-elder@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the SpacemiT K1 SoC QSPI IP to the list of supported hardware. This
is the first non-Freescale device represented here. It has a nearly
identidal register set, and this binding correctly describes the hardware.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20251027133008.360237-2-elder@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A user reports that on their Lenovo Corsola Magneton with EC firmware
steelix-15194.270.0 the driver probe fails with EINVAL. It turns out
that the power LED does not contain any color components as indicated
by the following "ectool led power query" output:
Brightness range for LED 1:
red : 0x0
green : 0x0
blue : 0x0
yellow : 0x0
white : 0x0
amber : 0x0
The LED also does not react to commands sent manually through ectool and
is generally non-functional.
Instead of failing the probe for all LEDs managed by the EC when one
without color components is encountered, silently skip those.
Cc: stable@vger.kernel.org
Fixes: 8d6ce6f3ec ("leds: Add ChromeOS EC driver")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20251028-cros_ec-leds-no-colors-v1-1-ebe13a02022a@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
Initializing the regmap_ranges using direct assignment to the range_min
and range_max members is a slightly verbose. In general we can make it a
tad cleaner when using the regmap_reg_range() macro.
The rohm-bd718x7.c is doing this open-coded initialization. It's not
really bad as there is only one range defined, but it is still worth
converting it to use the regmap_reg_range() so no-one uses it as a bad
example.
Additionally, the regmap_access_table expects a pointer to an array of
ranges. This is a tad more obvious when we use an array with single
range, instead of claiming a pointer to a range struct being a single
element array.
Use regmap_reg_range() when initializing the regmap_range structure and
use a real one-element array instead of a pointer to a struct.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/aP9hlpRO-0vmEHBZ@mva-rohm
Signed-off-by: Lee Jones <lee@kernel.org>
These chips must be described as none of the block protection
information are discoverable. This chip supports 4 bits plus the
top/bottom addressing capability to identify the protected blocks.
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
These chips must be described as none of the block protection
information are discoverable. This chip supports 4 bits plus the
top/bottom addressing capability to identify the protected blocks.
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
These chips must be described as none of the block protection
information are discoverable. This chip supports 4 bits plus the
top/bottom addressing capability to identify the protected blocks.
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
These chips must be described as none of the block protection
information are discoverable. This chip supports 4 bits plus the
top/bottom addressing capability to identify the protected blocks.
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
These chips must be described as none of the block protection
information are discoverable. This chip supports 4 bits plus the
top/bottom addressing capability to identify the protected blocks.
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
This chip must be described as none of the block protection information
are discoverable. This chip supports 4 bits plus the top/bottom
addressing capability to identify the protected blocks.
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
MAX77620 is most likely always a single device on the board, however
nothing stops board designers to have two of them, thus same device
driver could probe twice. Or user could manually try to probing second
time.
Device driver is not ready for that case, because it allocates
statically 'struct regmap_irq_chip' as non-const and stores during
probe in 'irq_drv_data' member a pointer to per-probe state
container ('struct max77620_chip'). devm_regmap_add_irq_chip() does not
make a copy of 'struct regmap_irq_chip' but store the pointer.
Second probe - either successful or failure - would overwrite the
'irq_drv_data' from previous device probe, so interrupts would be
executed in a wrong context.
Cc: stable@vger.kernel.org
Fixes: 3df140d11c ("mfd: max77620: Mask/unmask interrupt before/after servicing it")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251023101939.67991-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Mark 'interrupts', 'interrupt-controller', and 'interrupt-cells' as
optional in the binding schema.
The 'interrupts' property should not be required for the TPS65910 PMIC.
On the AM335x-ICEV2 SoC, there is no hardware connection from the PMIC_INT
pin to the SoC. Without the 'interrupts' property defined, the PMIC cannot
forward interrupts.
Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251021182716.292652-1-s-ramamoorthy@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
Allow wakeup-source property to below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-emcon-avari.dtb: pmic@58 (dlg,da9063): onkey: 'wakeup-source' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251014184114.2353199-1-Frank.Li@nxp.com
Signed-off-by: Lee Jones <lee@kernel.org>
When da9055_device_init() fails after regmap_add_irq_chip()
succeeds but mfd_add_devices() fails, the error handling path
only calls mfd_remove_devices() but forgets to call
regmap_del_irq_chip(). This results in a resource leak.
Fix this by adding regmap_del_irq_chip() to the error path so
that resources are released properly.
Fixes: 2896434cf2 ("mfd: DA9055 core driver")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20251010011737.1078-1-vulab@iscas.ac.cn
Signed-off-by: Lee Jones <lee@kernel.org>
This PMIC is referenced in upstream DTs for the Renesas Lager and
Koelsch boards. Sadly, there is no documentation available. This minimal
binding description states the facts that we do know.
Fixes:
arch/arm/boot/dts/renesas/r8a7790-lager.dtb: /soc/spi@e6e10000/pmic@0: failed to match any schema with compatible: ['renesas,r2a11302ft']
arch/arm/boot/dts/renesas/r8a7791-koelsch.dtb: /soc/spi@e6e20000/pmic@0: failed to match any schema with compatible: ['renesas,r2a11302ft']
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251010094734.10487-2-wsa+renesas@sang-engineering.com
Signed-off-by: Lee Jones <lee@kernel.org>
The second address can be used as a shortcut to access register pages
2+3. The driver does not use this feature yet. The second address should
still be marked as used, otherwise userspace could interfere with the
driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20251023065610.2855-2-wsa+renesas@sang-engineering.com
Signed-off-by: Lee Jones <lee@kernel.org>
The wl1273 FM radio is on Arnd's unused driver list:
https://lore.kernel.org/lkml/a15bb180-401d-49ad-a212-0c81d613fbc8@app.fastmail.com/
Other patches have removed the core, the ASoC code and the Radio code.
With all those in, remove the header.
Also, tidy the ref in the docs.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee@kernel.org>
Add interrupt-controller property, because max77705 has dedicated interrupt
source register to determine which sub device triggered an interrupt.
Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Make sure to drop the reference taken to the sysmgr platform device when
retrieving its driver data.
Note that holding a reference to a device does not prevent its driver
data from going away.
Fixes: f36e789a1f ("mfd: altera-sysmgr: Add SOCFPGA System Manager")
Cc: stable@vger.kernel.org # 5.2
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Mark the write buffer arguments in apple_smc_write(), apple_smc_rw(),
and apple_smc_write_atomic() as const. These functions do not modify
the data provided by the caller, so the parameters should be const
qualified.
Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
Reviewed-by: Sven Peter <sven@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Nothing seems to prevent this driver from being compile tested so allow
that.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
To be able to fully describe how the SY7636A is connected to the system,
add properties for the EN and VCOM_EN pins. To squeeze out every bit
of unused current, in many devices it is possible to power off the
complete chip. Add an input regulator to allow that.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Andreas Kemnade <akemnade@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
When using the _SMC_KEY macro in switch/case statements, GCC 15.2.1 errors
out with 'case label does not reduce to an integer constant'. Introduce
a new __SMC_KEY macro that can be used instead.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Link: https://patch.msgid.link/20251025-macsmc-subdevs-v4-5-374d5c9eba0e@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
In target mode, the clock signal is controlled by the master. Target does
not need to check, calculate and configure the clock frequency division.
The target can directly use the root clock to sample the SCL signal.
Therefore, remove check, calculation and frequency division function of
the clock for target mode.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20251024055211.408440-1-carlos.song@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The validator is not happy:
Warning: drivers/regulator/pf9453-regulator.c:303 This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
Update the kernel-doc accordingly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20251106114628.2302762-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:
This series adds support for three new MediaTek PMICs: MT6316, MT6363
and MT6373 and their variants - used in board designs featuring the
MediaTek MT8196 Chromebook SoC, or the MT6991 Dimensity 9400 Smartphone
SoC.
In particular, MT6316 is a regulator, but the MT6363 and MT6373 PMICs
are multi-function devices, as they have and expose multiple sub-devices;
moreover, some of those also contain an interrupt controller, managing
internal IPs interrupts: for those, a chained interrupt handler is
registered, which parent is the SPMI controller itself.
This series adds support for all of the MT6316 regulator variants and
for MT6363, MT6373 SPMI PMICs and their interrupt controller.
Correct the kernel-doc comments format to avoid around 35 kernel-doc
warnings:
- use struct keyword to introduce struct kernel-doc comments
- use correct variable name for some struct members
- use correct function name in comments for some functions
- fix spelling in a few comments
- use a ':' instead of '-' to separate struct members from their
descriptions
- add a function name heading for rvt_div_mtu()
This leaves one struct member that is not described:
rdmavt_qp.h:206: warning: Function parameter or struct member 'wq'
not described in 'rvt_krwq'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20251105045127.106822-1-rdunlap@infradead.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
CC: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251101163121.78400-6-marco.crivellari@suse.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
CC: Yishai Hadas <yishaih@nvidia.com>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251101163121.78400-5-marco.crivellari@suse.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
CC: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251101163121.78400-4-marco.crivellari@suse.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251101163121.78400-3-marco.crivellari@suse.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
Adding system_dfl_wq to encourage its use when unbound work should be used.
The old system_unbound_wq will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251101163121.78400-2-marco.crivellari@suse.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Need to take an SRQ lock in poll_cq before moving SRQ tail.
Signed-off-by: Jay Bhat <jay.bhat@intel.com>
Reviewed-by: Jacob Moroni <jmoroni@google.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251031021726.1003-7-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
On new platforms greater than QM_HW_V3, the migration region has been
relocated from the VF to the PF. The VF's own configuration space is
restored to the complete 64KB, and there is no need to divide the
size of the BAR configuration space equally. The driver should be
modified accordingly to adapt to the new hardware device.
On the older hardware platform QM_HW_V3, the live migration configuration
region is placed in the latter 32K portion of the VF's BAR2 configuration
space. On the new hardware platform QM_HW_V4, the live migration
configuration region also exists in the same 32K area immediately following
the VF's BAR2, just like on QM_HW_V3.
However, access to this region is now controlled by hardware. Additionally,
a copy of the live migration configuration region is present in the PF's
BAR2 configuration space. On the new hardware platform QM_HW_V4, when an
older version of the driver is loaded, it behaves like QM_HW_V3 and uses
the configuration region in the VF, ensuring that the live migration
function continues to work normally. When the new version of the driver is
loaded, it directly uses the configuration region in the PF. Meanwhile,
hardware configuration disables the live migration configuration region
in the VF's BAR2: reads return all 0xF values, and writes are silently
ignored.
Signed-off-by: Longfang Liu <liulongfang@huawei.com>
Reviewed-by: Shameer Kolothum <shameerkolothum@gmail.com>
Link: https://lore.kernel.org/r/20251030015744.131771-3-liulongfang@huawei.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
On new platforms greater than QM_HW_V3, the configuration region for the
live migration function of the accelerator device is no longer
placed in the VF, but is instead placed in the PF.
Therefore, the configuration region of the live migration function
needs to be opened when the QM driver is loaded. When the QM driver
is uninstalled, the driver needs to clear this configuration.
Signed-off-by: Longfang Liu <liulongfang@huawei.com>
Reviewed-by: Shameer Kolothum <shameerkolothum@gmail.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Link: https://lore.kernel.org/r/20251030015744.131771-2-liulongfang@huawei.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Store the tools/testing/selftests/vfio/lib outputs (e.g. object files)
in $(OUTPUT)/libvfio rather than in $(OUTPUT)/lib. This is in
preparation for building the VFIO selftests library into the KVM
selftests (see Link below).
Specifically this will avoid name conflicts between
tools/testing/selftests/{vfio,kvm/lib and also avoid leaving behind
empty directories under tools/testing/selftests/kvm after a make clean.
Link: https://lore.kernel.org/kvm/20250912222525.2515416-2-dmatlack@google.com/
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20250922224857.2528737-1-dmatlack@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Add a driver for the regulators found on the MT6363 PMIC, fully
controlled by SPMI interface.
This PMIC regulates voltage with an input range of 2.6-5.0V, and
features 10 buck converters and 26 LDOs.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251027110527.21002-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add bindings for the regulators found in the MediaTek MT6363 PMIC,
usually found in board designs using the MT6991 Dimensity 9400 and
on MT8196 Kompanio SoC for Chromebooks, along with the MT6316 and
MT6373 PMICs.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251027110527.21002-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a driver for the regulators found on all types of the MediaTek
MT6316 SPMI PMIC, fully controlled by SPMI interface and featuring
four step down DCDC (buck) converters.
In particular, this includes support for:
- MT6316(BP/VP): 2+2 Phase (Phase 1: buck1+2, Phase 2: buck3+4)
- MT6316(CP/HP/KP): 3+1 Phase (Phase 1: buck1+2+4, Phase 2: buck3)
- MT6316(DP/TP): 4+0 Phase (Single phase, buck1+2+3+4)
Please note that the set/clear registers for the enable bits are
not documented in the datasheet version that I used as reference,
but those are used in the downstream driver and I verified that
are actually working as expected.
Besides, it's also worth clearly mentioning that the MT6316 PMICs
voltage selector register uses a weird 9-bits Big Endian format,
for which a driver-private helper is provided.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251027110527.21002-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add bindings for the regulators found in the MediaTek MT6316 PMIC,
usually found in board designs using the MT6991 Dimensity 9400 and
on MT8196 Kompanio SoC for Chromebooks.
This chip is fully controlled by SPMI and has multiple variants
providing different phase configurations.
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251027110527.21002-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add bcm2712-pm compatible and update the bindings to satisfy it's
requirements. The PM hardware block inside bcm2712 lacks the "asb"
and "rpivid_asb" register ranges and also does not have clocks, update
the bindings accordingly.
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Merge series from Vishwaroop A <va@nvidia.com>:
This patch series addresses timeout handling issues in the Tegra QSPI driver
that occur under high system load conditions. We've observed that when CPUs
are saturated (due to error injection, RAS firmware activity, or general CPU
contention), QSPI interrupt handlers can be delayed, causing spurious transfer
failures even though the hardware completed the operation successfully.
These changes have been tested in production environments under various high
load scenarios including RAS testing and CPU saturation workloads.
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
The old wq (system_wq) will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://lore.kernel.org/r/20251031111628.143924-2-marco.crivellari@suse.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add some basic checks that the sw_bit APIs work as expected.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Currently a incoherent walk domain cannot be attached to a coherent
capable iommu. Kevin says HW probably doesn't exist with such a mixture,
but making the driver support it makes logical sense anyhow.
When building the PASID entry the PWSNP (Page Walk Snoop) bit tells the HW
if it should issue snoops. If the page table is cache flushed because of
PT_FEAT_DMA_INCOHERENT then it is fine to set this bit to 0 even if the HW
supports 1.
Weaken the compatible check to permit a coherent instance to accept an
incoherent table and fix the PASID table construction to set PWSNP from
PT_FEAT_DMA_INCOHERENT.
SVA always sets PWSNP.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Replace the VT-d iommu_domain implementation of the VT-d second stage and
first stage page tables with the iommupt VTDSS and x86_64
pagetables. x86_64 is shared with the AMD driver.
There are a couple notable things in VT-d:
- Like AMD the second stage format is not sign extended, unlike AMD it
cannot decode a full 64 bits. The first stage format is a normal sign
extended x86 page table
- The HW caps can indicate how many levels, how many address bits and what
leaf page sizes are supported in HW. As before the highest number of
levels that can translate the entire supported address width is used.
The supported page sizes are adjusted directly from the dedicated
first/second stage cap bits.
- VTD requires flushing 'write buffers'. This logic is left unchanged,
the write buffer flushes on any gather flush or through iotlb_sync_map.
- Like ARM, VTD has an optional non-coherent page table walker that
requires cache flushing. This is supported through PT_FEAT_DMA_INCOHERENT
the same as ARM, however x86 can't use the DMA API for flush, it must
call the arch function clflush_cache_range()
- The PT_FEAT_DYNAMIC_TOP can probably be supported on VT-d someday for the
second stage when it uses 128 bit atomic stores for the HW context
structures.
- PT_FEAT_VTDSS_FORCE_WRITEABLE is used to work around ERRATA_772415_SPR17
- A kernel command line parameter "sp_off" disables all page sizes except
4k
Remove all the unused iommu_domain page table code. The debugfs paths have
their own independent page table walker that is left alone for now.
This corrects a race with the non-coherent walker that the ARM
implementations have fixed:
CPU 0 CPU 1
pfn_to_dma_pte() pfn_to_dma_pte()
pte = &parent[offset];
if (!dma_pte_present(pte)) {
try_cmpxchg64(&pte->val)
pte = &parent[offset];
.. dma_pte_present(pte) ..
[...]
// iommu_map() completes
// Device does DMA
domain_flush_cache(pte)
The CPU 1 mapping operation shares a page table level with the CPU 0
mapping operation. CPU 0 installed a new page table level but has not
flushed it yet. CPU1 returns from iommu_map() and the device does DMA. The
non coherent walker fails to see the new table level installed by CPU 0
and fails the DMA with non-present.
The iommupt PT_FEAT_DMA_INCOHERENT implementation uses the ARM design of
storing a flag when CPU 0 completes the flush. If the flag is not set CPU
1 will also flush to ensure the HW can fully walk to the PTE being
installed.
Cc: Tina Zhang <tina.zhang@intel.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
VT-d requires PT_FEAT_DMA_INCOHERENT for the x86 page table as well,
implement the required SW bits and enable the feature.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
AMD and VTD are historically different here, adopt the VTD version of
setting the D bit only on writable PTEs as it makes more sense.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The VT-d second stage format is almost the same as the x86 PAE format,
except the bit encodings in the PTE are different and a few new PTE
features, like force coherency are present.
Among all the formats it is unique in not having a designated present bit.
Comparing the performance of several operations to the existing version:
iommu_map()
pgsz ,avg new,old ns, min new,old ns , min % (+ve is better)
2^12, 53,66 , 50,64 , 21.21
2^21, 59,70 , 56,67 , 16.16
2^30, 54,66 , 52,63 , 17.17
256*2^12, 384,524 , 337,516 , 34.34
256*2^21, 387,632 , 336,626 , 46.46
256*2^30, 376,629 , 323,623 , 48.48
iommu_unmap()
pgsz ,avg new,old ns, min new,old ns , min % (+ve is better)
2^12, 67,86 , 63,84 , 25.25
2^21, 64,84 , 59,80 , 26.26
2^30, 59,78 , 56,74 , 24.24
256*2^12, 216,335 , 198,317 , 37.37
256*2^21, 245,350 , 232,344 , 32.32
256*2^30, 248,345 , 226,339 , 33.33
Cc: Tina Zhang <tina.zhang@intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Flush the CPU cache for the page table memory after each set of writes to
the page table. The iommu should have visibility to the updated entries as
soon as the map/unmap/etc operations return, like normal coherent hardware
does.
The caches also have to be flushed before any gather can be submitted to
the driver.
Implement the same solution to the race as io-pgtable-arm by using a
software PTE bit to track if a table entry has been flushed or not. If
another thread is still flushing then another concurrent map operation
could return without IOMMU visibility to a required table entry. The SW
bit will tell the second thread to also flush the cache.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This is the first step to supporting an incoherent walker, start and stop
the incoherence around the allocation and frees of the page table memory.
The iommu_pages API maps this to dma_map/unmap_single(), or arch cache
flushing calls.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
SW bits can be placed on items, including table entries, single OA's and
individual items within a contiguous OA. They are guaranteed to be ignored
by the HW. The API is very basic since the only use case so far is a
single bit.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Some IOMMU HW cannot snoop the CPU cache when it walks the IO page tables.
The CPU is required to flush the cache to make changes visible to the HW.
Provide some helpers from iommu-pages to manage this. The helpers combine
both the ARM and x86 (used in Intel VT-d) versions of the cache flushing
under a single API.
The ARM version uses the DMA API to access the cache flush on the
assumption that the iommu is using a direct mapping and is already marked
incoherent. The helpers will do the DMA API calls to set things up and
keep track of DMA mapped folios using a bit in the ioptdesc so that
unmapping on error paths is cleaner.
The Intel version just calls the arch cache flush call directly and has no
need to cleanup prior to destruction.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This intends to have high coverage of the page table format functions and
the IOMMU implementation itself, exercising the various corner cases.
The kunit tests can be run in the kunit framework, using commands like:
tools/testing/kunit/kunit.py run --build_dir build_kunit_arm64 --arch arm64 --make_options LLVM=-19 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig
tools/testing/kunit/kunit.py run --build_dir build_kunit_uml --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig
tools/testing/kunit/kunit.py run --build_dir build_kunit_x86_64 --arch x86_64 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig
tools/testing/kunit/kunit.py run --build_dir build_kunit_i386 --arch i386 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig
tools/testing/kunit/kunit.py run --build_dir build_kunit_i386pae --arch i386 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig --kconfig_add CONFIG_X86_PAE=y
There are several interesting corner cases on the 32 bit platforms that
need checking.
Like the generic tests, these are run on the format's configuration list
using kunit "params". This also checks the core iommu parts of the page
table code as it enters the logic through a mock iommu_domain.
The following are checked:
- PT_FEAT_DYNAMIC_TOP properly adds levels one by one
- Every page size can be iommu_map()'d, and mapping creates that size
- iommu_iova_to_phys() works with every page size
- Test converting OA -> non present -> OA when the two OAs overlap and
free table levels
- Test that unmap stops at holes, unmap doesn't split, and unmap returns
the right values for partial unmap requests
- Randomly map/unmap. Checks map with random sizes, that map fails when
hitting collisions doing nothing, unmap/map with random intersections and
full unmap of random sizes. Also checks iommu_iova_to_phys() with random
sizes
- Check for memory leaks by monitoring NR_SECONDARY_PAGETABLE
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Replace the io_pgtable versions with pt_iommu versions. The v2 page table
uses the x86 implementation that will be eventually shared with VT-d.
This supports the same special features as the original code:
- increase_top for the v1 format to allow scaling from 3 to 6 levels
- non-present flushing
- Dirty tracking for v1 only
- __sme_set() to adjust the PTEs for CC
- Optimization for flushing with virtualization to minimize the range
- amd_iommu_pgsize_bitmap override of the native page sizes
- page tables allocate from the device's NUMA node
Rework the domain ops so that v1/v2 get their own ops. Make dedicated
allocation functions for v1 and v2. Hook up invalidation for a top change
to struct pt_iommu_flush_ops. Delete some of the iopgtable related code
that becomes unused in this patch. The next patch will delete the rest of
it.
This fixes a race bug in AMD's increase_address_space() implementation. It
stores the top level and top pointer in different memory, which prevents
other threads from reading a coherent version:
increase_address_space() alloc_pte()
level = pgtable->mode - 1;
pgtable->root = pte;
pgtable->mode += 1;
pte = &pgtable->root[PM_LEVEL_INDEX(level, address)];
The iommupt version is careful to put mode and root under a single
READ_ONCE and then is careful to only READ_ONCE a single time per
walk.
Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This is used by x86 CPUs and can be used in AMD/VT-d x86 IOMMUs. When a
x86 IOMMU is running SVA the MM will be using this format.
This implementation follows the AMD v2 io-pgtable version.
There is nothing remarkable here, the format can have 4 or 5 levels and
limited support for different page sizes. No contiguous pages support.
x86 uses a sign extension mechanism where the top bits of the VA must
match the sign bit. The core code supports this through
PT_FEAT_SIGN_EXTEND which creates and upper and lower VA range. All the
new operations will work correctly in both spaces, however currently there
is no way to report the upper space to other layers. Future patches can
improve that.
In principle this can support 3 page tables levels matching the 32 bit PAE
table format, but no iommu driver needs this. The focus is on the modern
64 bit 4 and 5 level formats.
Comparing the performance of several operations to the existing version:
iommu_map()
pgsz ,avg new,old ns, min new,old ns , min % (+ve is better)
2^12, 71,61 , 66,58 , -13.13
2^21, 66,60 , 61,55 , -10.10
2^30, 59,56 , 56,54 , -3.03
256*2^12, 392,1360 , 345,1289 , 73.73
256*2^21, 383,1159 , 335,1145 , 70.70
256*2^30, 378,965 , 331,892 , 62.62
iommu_unmap()
pgsz ,avg new,old ns, min new,old ns , min % (+ve is better)
2^12, 77,71 , 73,68 , -7.07
2^21, 76,70 , 70,66 , -6.06
2^30, 69,66 , 66,63 , -4.04
256*2^12, 225,899 , 210,870 , 75.75
256*2^21, 262,722 , 248,710 , 65.65
256*2^30, 251,643 , 244,634 , 61.61
The small -ve values in the iommu_unmap() are due to the core code calling
iommu_pgsize() before invoking the domain op. This is unncessary with this
implementation. Future work optimizes this and gets to 2%, 4%, 3%.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The iommufd self test uses an xarray to store the pfns and their orders to
emulate a page table. Make it act more like a real iommu driver by
replacing the xarray with an iommupt based page table. The new AMDv1 mock
format behaves similarly to the xarray.
Add set_dirty() as a iommu_pt operation to allow the test suite to
simulate HW dirty.
Userspace can select between several formats including the normal AMDv1
format and a special MOCK_IOMMUPT_HUGE variation for testing huge page
dirty tracking. To make the dirty tracking test work the page table must
only store exactly 2M huge pages otherwise the logic the test uses
fails. They cannot be broken up or combined.
Aside from aligning the selftest with a real page table implementation,
this helps test the iommupt code itself.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The iommufd self test uses an xarray to store the pfns and their orders to
emulate a page table. Slightly modify the amdv1 page table to create a
real page table that has similar properties:
- 2k base granule to simulate something like a 4k page table on a 64K
PAGE_SIZE ARM system
- Contiguous page support for every PFN order
- Dirty tracking
AMDv1 is the closest format, as it is the only one that already supports
every page size. Tweak it to have only 5 levels and an 11 bit base granule
and compile it separately as a format variant.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This intends to have high coverage of the page table format functions, it
uses the IOMMU implementation to create a tree which it then walks through
and directly calls the generic page table functions to test them.
It is a good starting point to test a new format header as it is often
able to find typos and inconsistencies much more directly, rather than
with an obscure failure in the iommu implementation.
The tests can be run with commands like:
tools/testing/kunit/kunit.py run --build_dir build_kunit_arm64 --arch arm64 --make_options LLVM=-19 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig
tools/testing/kunit/kunit.py run --build_dir build_kunit_uml --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig --kconfig_add CONFIG_WERROR=n
tools/testing/kunit/kunit.py run --build_dir build_kunit_x86_64 --arch x86_64 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig
tools/testing/kunit/kunit.py run --build_dir build_kunit_i386 --arch i386 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig
tools/testing/kunit/kunit.py run --build_dir build_kunit_i386pae --arch i386 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig --kconfig_add CONFIG_X86_PAE=y
There are several interesting corner cases on the 32 bit platforms that
need checking.
The format can declare a list of configurations that generate different
configurations the initialize the page table, for instance with different
top levels or other parameters. The kunit will turn these into "params"
which cause each test to run multiple times.
The tests are repeated to run at every table level to check that all the
item encoding formats work.
The following are checked:
- Basic init works for each configuration
- The various log2 functions have the expected behavior at the limits
- pt_compute_best_pgsize() works
- pt_table_pa() reads back what pt_install_table() writes
- range.max_vasz_lg2 works properly
- pt_table_oa_lg2sz() and pt_table_item_lg2sz() use a contiguous
non-overlapping set of bits from the VA up to the defined max_va
- pt_possible_sizes() and pt_can_have_leaf() produces a sensible layout
- pt_item_oa(), pt_entry_oa(), and pt_entry_num_contig_lg2() read back
what pt_install_leaf_entry() writes
- pt_clear_entry() works
- pt_attr_from_entry() reads back what pt_iommu_set_prot() &
pt_install_leaf_entry() writes
- pt_entry_set_write_clean(), pt_entry_make_write_dirty(), and
pt_entry_write_is_dirty() work
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
IOMMU HW now supports updating a dirty bit in an entry when a DMA writes
to the entry's VA range. iommufd has a uAPI to read and clear the dirty
bits from the tables.
This is a trivial recursive descent algorithm to read and optionally clear
the dirty bits. The format needs a function to tell if a contiguous entry
is dirty, and a function to clear a contiguous entry back to clean.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
map is slightly complicated because it has to handle a number of special
edge cases:
- Overmapping a previously shared, but now empty, table level with an OA.
Requries validating and freeing the possibly empty tables
- Doing the above across an entire to-be-created contiguous entry
- Installing a new shared table level concurrently with another thread
- Expanding the table by adding more top levels
Table expansion is a unique feature of AMDv1, this version is quite
similar except we handle racing concurrent lockless map. The table top
pointer and starting level are encoded in a single uintptr_t which ensures
we can READ_ONCE() without tearing. Any op will do the READ_ONCE() and use
that fixed point as its starting point. Concurrent expansion is handled
with a table global spinlock.
When inserting a new table entry map checks that the entire portion of the
table is empty. This includes freeing any empty lower tables that will be
overwritten by an OA. A separate free list is used while checking and
collecting all the empty lower tables so that writing the new entry is
uninterrupted, either the new entry fully writes or nothing changes.
A special fast path for PAGE_SIZE is implemented that does a direct walk
to the leaf level and installs a single entry. This gives ~15% improvement
for iommu_map() when mapping lists of single pages.
This version sits under the iommu_domain_ops as map_pages() but does not
require the external page size calculation. The implementation is actually
map_range() and can do arbitrary ranges, internally handling all the
validation and supporting any arrangment of page sizes. A future series
can optimize iommu_map() to take advantage of this.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
unmap_pages removes mappings and any fully contained interior tables from
the given range. This follows the now-standard iommu_domain API definition
where it does not split up larger page sizes into smaller. The caller must
perform unmap only on ranges created by map or it must have somehow
otherwise determined safe cut points (eg iommufd/vfio use iova_to_phys to
scan for them)
A future work will provide 'cut' which explicitly does the page size split
if the HW can support it.
unmap is implemented with a recursive descent of the tree. If the caller
provides a VA range that spans an entire table item then the table memory
can be freed as well.
If an entire table item can be freed then this version will also check the
leaf-only level of the tree to ensure that all entries are present to
generate -EINVAL. Many of the existing drivers don't do this extra check.
This version sits under the iommu_domain_ops as unmap_pages() but does not
require the external page size calculation. The implementation is actually
unmap_range() and can do arbitrary ranges, internally handling all the
validation and supporting any arrangment of page sizes. A future series
can optimize __iommu_unmap() to take advantage of this.
Freed page table memory is batched up in the gather and will be freed in
the driver's iotlb_sync() callback after the IOTLB flush completes.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
iova_to_phys is a performance path for the DMA API and iommufd, implement
it using an unrolled get_user_pages() like function waterfall scheme.
The implementation itself is fairly trivial.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
AMD IOMMU v1 is unique in supporting contiguous pages with a variable size
and it can decode the full 64 bit VA space. Unlike other x86 page tables
this explicitly does not do sign extension as part of allowing the entire
64 bit VA space to be supported.
The general design is quite similar to the x86 PAE format, except with a
6th level and quite different PTE encoding.
This format is the only one that uses the PT_FEAT_DYNAMIC_TOP feature in
the existing code as the existing AMDv1 code starts out with a 3 level
table and adds levels on the fly if more IOVA is needed.
Comparing the performance of several operations to the existing version:
iommu_map()
pgsz ,avg new,old ns, min new,old ns , min % (+ve is better)
2^12, 65,64 , 62,61 , -1.01
2^13, 70,66 , 67,62 , -8.08
2^14, 73,69 , 71,65 , -9.09
2^15, 78,75 , 75,71 , -5.05
2^16, 89,89 , 86,84 , -2.02
2^17, 128,121 , 124,112 , -10.10
2^18, 175,175 , 170,163 , -4.04
2^19, 264,306 , 261,279 , 6.06
2^20, 444,525 , 438,489 , 10.10
2^21, 60,62 , 58,59 , 1.01
256*2^12, 381,1833 , 367,1795 , 79.79
256*2^21, 375,1623 , 356,1555 , 77.77
256*2^30, 356,1338 , 349,1277 , 72.72
iommu_unmap()
pgsz ,avg new,old ns, min new,old ns , min % (+ve is better)
2^12, 76,89 , 71,86 , 17.17
2^13, 79,89 , 75,86 , 12.12
2^14, 78,90 , 74,86 , 13.13
2^15, 82,89 , 74,86 , 13.13
2^16, 79,89 , 74,86 , 13.13
2^17, 81,89 , 77,87 , 11.11
2^18, 90,92 , 87,89 , 2.02
2^19, 91,93 , 88,90 , 2.02
2^20, 96,95 , 91,92 , 1.01
2^21, 72,88 , 68,85 , 20.20
256*2^12, 372,6583 , 364,6251 , 94.94
256*2^21, 398,6032 , 392,5758 , 93.93
256*2^30, 396,5665 , 389,5258 , 92.92
The ~5-17x speedup when working with mutli-PTE map/unmaps is because the
AMD implementation rewalks the entire table on every new PTE while this
version retains its position. The same speedup will be seen with dirtys as
well.
The old implementation triggers a compiler optimization that ends up
generating a "rep stos" memset for contiguous PTEs. Since AMD can have
contiguous PTEs that span 2Kbytes of table this is a huge win compared to
a normal movq loop. It is why the unmap side has a fairly flat runtime as
the contiguous PTE sides increases. This version makes it explicit with a
memset64() call.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The existing IOMMU page table implementations duplicate all of the working
algorithms for each format. By using the generic page table API a single C
version of the IOMMU algorithms can be created and re-used for all of the
different formats used in the drivers. The implementation will provide a
single C version of the iommu domain operations: iova_to_phys, map, unmap,
and read_and_clear_dirty.
Further, adding new algorithms and techniques becomes easy to do across
the entire fleet of drivers and formats.
The C functions are drop in compatible with the existing iommu_domain_ops
using the IOMMU_PT_DOMAIN_OPS() macro. Each per-format implementation
compilation unit will produce exported symbols following the pattern
pt_iommu_FMT_map_pages() which the macro directly maps to the
iommu_domain_ops members. This avoids the additional function pointer
indirection like io-pgtable has.
The top level struct used by the drivers is pt_iommu_table_FMT. It
contains the other structs to allow container_of() to move between the
driver, iommu page table, generic page table, and generic format layers.
struct pt_iommu_table_amdv1 {
struct pt_iommu {
struct iommu_domain domain;
} iommu;
struct pt_amdv1 {
struct pt_common common;
} amdpt;
};
The driver is expected to union the pt_iommu_table_FMT with its own
existing domain struct:
struct driver_domain {
union {
struct iommu_domain domain;
struct pt_iommu_table_amdv1 amdv1;
};
};
PT_IOMMU_CHECK_DOMAIN(struct driver_domain, amdv1, domain);
To create an alias to avoid renaming 'domain' in a lot of driver code.
This allows all the layers to access all the necessary functions to
implement their different roles with no change to any of the existing
iommu core code.
Implement the basic starting point: pt_iommu_init(), get_info() and
deinit().
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add some general description and pull in the kdoc comments from the source
file to index most of the useful functions.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The generic API is intended to be separated from the implementation of
page table algorithms. It contains only accessors for walking and
manipulating the table and helpers that are useful for building an
implementation. Memory management is not in the generic API, but part of
the implementation.
Using a multi-compilation approach the implementation module would include
headers in this order:
common.h
defs_FMT.h
pt_defs.h
FMT.h
pt_common.h
IMPLEMENTATION.h
Where each compilation unit would have a combination of FMT and
IMPLEMENTATION to produce a per-format per-implementation module.
The API is designed so that the format headers have minimal logic, and
default implementations are provided if the format doesn't include one.
Generally formats provide their code via an inline function using the
pattern:
static inline FMTpt_XX(..) {}
#define pt_XX FMTpt_XX
The common code then enforces a function signature so that there is no
drift in function arguments, or accidental polymorphic functions (as has
been slightly troublesome in mm). Use of function-like #defines are
avoided in the format even though many of the functions are small enough.
Provide kdocs for the API surface.
This is enough to implement the 8 initial format variations with all of
their features:
* Entries comprised of contiguous blocks of IO PTEs for larger page
sizes (AMDv1, ARMv8)
* Multi-level tables, up to 6 levels. Runtime selected top level
* The size of the top table level can be selected at runtime (ARM's
concatenated tables)
* The number of levels in the table can optionally increase dynamically
during map (AMDv1)
* Optional leaf entries at any level
* 32 bit/64 bit virtual and output addresses, using every bit
* Sign extended addressing (x86)
* Dirty tracking
A basic simple format takes about 200 lines to declare the require inline
functions.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Tested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Under high system load, QSPI interrupts can be delayed or blocked on the
target CPU, causing wait_for_completion_timeout() to report failure even
though the hardware successfully completed the transfer.
When a timeout occurs, check the QSPI_RDY bit in QSPI_TRANS_STATUS to
determine if the hardware actually completed the transfer. If so, manually
invoke the completion handler to process the transfer successfully instead
of failing it.
This distinguishes lost/delayed interrupts from real hardware timeouts,
preventing unnecessary failures of transfers that completed successfully.
Signed-off-by: Vishwaroop A <va@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20251028155703.4151791-4-va@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Extract common cleanup code into dedicated helper functions to simplify
the code and improve readability. This refactoring includes:
- tegra_qspi_reset(): Device reset and interrupt cleanup
- tegra_qspi_dma_stop(): DMA termination and disable
- tegra_qspi_pio_stop(): PIO mode disable
No functional changes. This is purely a code reorganization to prepare
for improved timeout handling in subsequent patches.
Signed-off-by: Vishwaroop A <va@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20251028155703.4151791-3-va@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When the CPU that the QSPI interrupt handler runs on (typically CPU 0)
is excessively busy, it can lead to rare cases of the IRQ thread not
running before the transfer timeout is reached.
While handling the timeouts, any pending transfers are cleaned up and
the message that they correspond to is marked as failed, which leaves
the curr_xfer field pointing at stale memory.
To avoid this, clear curr_xfer to NULL upon timeout and check for this
condition when the IRQ thread is finally run.
While at it, also make sure to clear interrupts on failure so that new
interrupts can be run.
A better, more involved, fix would move the interrupt clearing into a
hard IRQ handler. Ideally we would also want to signal that the IRQ
thread no longer needs to be run after the timeout is hit to avoid the
extra check for a valid transfer.
Fixes: 921fc1838f ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Vishwaroop A <va@nvidia.com>
Link: https://patch.msgid.link/20251028155703.4151791-2-va@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use ARRAY_SIZE() instead of hard coded numbers to show the intention
and make code robust against potential changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20251103180946.604127-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Joy Zou <joy.zou@nxp.com>:
For the details, please check the patch commit log.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
Joy Zou (3):
regulator: pf9453: change the device ID register address
regulator: pf9453: remove low power mode
regulator: pf9453: remove unused I2C_LT register
drivers/regulator/pf9453-regulator.c | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
---
base-commit: 98bd8b16ae57e8f25c95d496fcde3dfdd8223d41
change-id: 20251103-b4-next-pf9453-c9f8fb6e0c10
Best regards,
--
Joy Zou <joy.zou@nxp.com>
In iommu_mmio_write(), it validates the user-provided offset with the
check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`.
This assumes a 4-byte access. However, the corresponding
show handler, iommu_mmio_show(), uses readq() to perform an 8-byte
(64-bit) read.
If a user provides an offset equal to `mmio_phys_end - 4`, the check
passes, and will lead to a 4-byte out-of-bounds read.
Fix this by adjusting the boundary check to use sizeof(u64), which
corresponds to the size of the readq() operation.
Fixes: 7a4ee419e8 ("iommu/amd: Add debugfs support to dump IOMMU MMIO registers")
Signed-off-by: Songtang Liu <liusongtang@bytedance.com>
Reviewed-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Tested-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add a region sysfs attribute to show the size of the extended linear
cache if there is any. The attribute is invisible when the cache
size is 0, which indicates it does not exist.
Moved the cxl_region_visible() location in order to pick up the
new sysfs attribute definition.
[ dj: Fixed spelling errors noted by Benjamin ]
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20251022203052.4078527-1-dave.jiang@intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
The cxl_acpi module spams "Extended linear cache calculation failed"
when the hmat memory target is not found for a node. This is normal
when the memory target does not contain extended linear cache
attributes. Adjust cxl_acpi_set_cache_size() to just return 0 if error
is returned from hmat_get_extended_linear_cache_size(). That is the
only error returned from hmat_get_extended_linear_cache_size() as
-ENOENT.
Also remove the check for -EOPNOTSUPP in cxl_setup_extended_linear_cache()
since that errno is never returned by cxl_acpi_set_cache_size().
[dj: Flipped minor return logic suggested by Jonathan ]
Suggested-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20251003185509.3215900-1-dave.jiang@intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Add a loadable test module that validates CXL address translation
calculations using parameterized test vectors. The module tests both
host-to-device and device-to-host address translations for Modulo and
XOR interleave arithmetic.
Two types of testing are provided:
1. Parameterized test vectors:
Test vectors are passed as module parameters in the format:
"dpa pos r_eiw r_eig hb_ways math expected_spa".
Round-trip validation is performed:
- Translate a DPA and position to a SPA
- Verify the result matches expected SPA
- Translate that SPA back to a DPA and position
- Verify round-trip consistency
2. Internal validation testing:
When no test vectors are provided, the module performs validation
of the translation functions by checking parameter boundaries and
running 10,000 iterations of randomly generated valid parameters
to exercise the core calculation functions.
The module uses the CXL Driver translation functions through symbols
exported exclusively for cxl_translate.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
In preparation for adding a test module that can exercise the address
translation functions performed by the CXL Driver, refactor the XOR
implementation like this:
- Extract the core calculation into a standalone helper function,
- Export the new function for use by test module cxl_translate only,
- Enhance the parameter validation since this new function will be
called from a test module with no guarantee of valid parameters,
- Move the define of struct cxl_cxims_data to cxl.h so the test module
can build xormaps.
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
In preparation for adding a test module that exercises the address
translation calculations, extract the core calculations into stand-
alone functions that operate on base parameters without dependencies
on struct cxl_region.
Perform additional parameter validation to protect against a test
module sending bad parameters. Export the validation function, as
well as the three core translation functions for use by test module
cxl_translate only.
This refactoring enables unit testing of the address translation logic
with controlled inputs, while preserving identical functionality in
the existing code paths.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
The old wq (system_wq) will be kept for a few release cycles.
See 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
for cause of changes.
[ dj: Add reference to commit that initiated the change. ]
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Acked-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>> ---
Link: https://patch.msgid.link/20251030163839.307752-1-marco.crivellari@suse.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
devm_cxl_port_enumerate_dports() is not longer used after below commit
commit 4f06d81e7c ("cxl: Defer dport allocation for switch ports")
Delete it and the relevant interface implemented in cxl_test.
Signed-off-by: Li Ming <ming.li@zohomail.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
The node/zone quirk section of the cxl documentation is incorrect.
The actual reason for fallback allocation misbehavior in the
described configuration is due to a kswapd/reclaim thrashing scenario
fixed by the linked patch. Remove this section.
Link: https://lore.kernel.org/linux-mm/20250919162134.1098208-1-hannes@cmpxchg.org/
Signed-off-by: Gregory Price <gourry@gourry.net>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Add the Glymur DPU compatible to clients compatible list, as it needs
the workarounds.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Qualcomm Kaanapali and Glymur SoCs include apps smmu that implements
arm,mmu-500, which is used to translate device-visible virtual addresses
to physical addresses. Add compatible for these items.
Co-developed-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
The charge control disabling does not work as expected and needs
more time to be figured out correctly. Drop this feature for now.
Reported-by: Val Packett <val@packett.cool>
Closes: https://lore.kernel.org/all/8f003bfb-8279-4c65-a271-c1e4a029043d@packett.cool/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Remove unnecessary register OTP_Ver and change the device ID address to
0x1. Previous version chip is never mass production. So not broken
compatibility.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Link: https://patch.msgid.link/20251103-b4-next-pf9453-v1-1-a025d536eee1@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Correct most kernel-doc warnings in include/linux/mtd/spear_smi.h
by adding a leading '@' to the description of struct members.
Add a new description for the missing @np member.
Warning: spear_smi.h:48 struct member 'name' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'mem_base' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'size' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'partitions' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'nr_partitions' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'fast_mode' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:62 struct member 'clk_rate' not described
in 'spear_smi_plat_data'
Warning: spear_smi.h:62 struct member 'num_flashes' not described
in 'spear_smi_plat_data'
Warning: spear_smi.h:62 struct member 'board_flash_info' not described
in 'spear_smi_plat_data'
Warning: spear_smi.h:62 struct member 'np' not described
in 'spear_smi_plat_data'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Add support for RT9756 smart cap divider charger.
The RT9759 is a high efficiency and high charge current charger. The
maximum charge current is up to 8A. It integrates a dual-phase charge
pump core with ADC monitoring.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://patch.msgid.link/f682812069b6be2138bfdae2ff9a9c84994d5b64.1761894605.git.cy_huang@richtek.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This driver implements poweroff/reboot support for the SpacemiT P1 PMIC
chip, which is commonly paired with the SpacemiT K1 SoC.
The SpacemiT P1 support is implemented as a MFD driver, so the access is
done directly through the regmap interface. Reboot or poweroff is
triggered by setting a specific bit in a control register, which is
automatically cleared by the hardware afterwards.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Link: https://patch.msgid.link/20251102230352.914421-2-aurelien@aurel32.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Mirroring drivers/macintosh/apm_emu.c, this means that
modprobe apm_power && modprobe $anotherdriver && modprobe -r apm_power
leaves $anotherdriver's apm_get_power_status instead of deleting it.
Fixes: 3788ec932b ("[BATTERY] APM emulation driver for class batteries")
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Link: https://patch.msgid.link/xczpgox57hxbunkcbdl5fxhc4gnsajsipldfidi7355afezk64@tarta.nabijaczleweli.xyz
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The build of intel_dc_ti_battery module on i386 (32-bit) fails with
ERROR: modpost: "__udivdi3" [drivers/power/supply/intel_dc_ti_battery.ko]
This is caused by 64-bit division of ktime values by NSEC_PER_USEC. Use
ktime_divns() helper which handles the division correctly on 32-bit
architectures.
Fixes: 8c5795fe55 ("power: supply: Add new Intel Dollar Cove TI battery driver")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Link: https://patch.msgid.link/20251015075957.8F40620057@lion.mk-sys.cz
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Clean up grammar, punctuation, etc., in the power supply class
documentation.
Add article adjectives where needed.
Hyphenate some adjectives.
Fix punctuation.
Fix some verb usage (singular/plural).
Fix run-on sentences.
Add "is" in a few places.
Change "QA" to "Q&A".
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://patch.msgid.link/20251014182008.823980-1-rdunlap@infradead.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Existing userspace (in particular, upower) disables charge control by
setting the start threshold to 0 and the stop threshold to 100.
Handle that by actually setting the enable bit to 0 when a start
threshold of 0 was requested.
Fixes: cc3e883a06 ("power: supply: qcom_battmgr: Add charge control support")
Signed-off-by: Val Packett <val@packett.cool>
Link: https://patch.msgid.link/20251012233333.19144-4-val@packett.cool
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The sysfs API documentation says that drivers "round written values to
the nearest supported value" for charge_control_end_threshold.
Let's do this for both thresholds, as userspace (e.g. upower) generally
does not expect these writes to fail at all.
Fixes: cc3e883a06 ("power: supply: qcom_battmgr: Add charge control support")
Signed-off-by: Val Packett <val@packett.cool>
Link: https://patch.msgid.link/20251012233333.19144-3-val@packett.cool
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Since wm831x_set_bits() may return error, log failure and exit from
wm831x_usb_limit_change() in such case.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 626b6cd5f5 ("power: wm831x_power: Support USB charger current limit management")
Signed-off-by: Ivan Abramov <i.abramov@mt-integration.ru>
Link: https://patch.msgid.link/20251009170553.566561-1-i.abramov@mt-integration.ru
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
There is a typo in rt9467_set_value_from_ranges() that can cause leaving local
variable sel with an undefined value which is then used in regmap_field_write().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 6f7f70e3a8 ("power: supply: rt9467: Add Richtek RT9467 charger driver")
Signed-off-by: Murad Masimov <m.masimov@mt-integration.ru>
Link: https://patch.msgid.link/20251009145308.1830893-1-m.masimov@mt-integration.ru
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The return value of rt9467_set_value_from_ranges() when setting AICL VTH is
not checked, even though it may fail.
Log error and return from rt9467_run_aicl() on fail.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 6f7f70e3a8 ("power: supply: rt9467: Add Richtek RT9467 charger driver")
Signed-off-by: Ivan Abramov <i.abramov@mt-integration.ru>
Link: https://patch.msgid.link/20251009144725.562278-1-i.abramov@mt-integration.ru
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Since iio_read_channel_processed() may fail, return its exit code on error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 814755c48f ("power: max17040: get thermal data from adc if available")
Signed-off-by: Ivan Abramov <i.abramov@mt-integration.ru>
Link: https://patch.msgid.link/20251008133648.559286-1-i.abramov@mt-integration.ru
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Since devm_delayed_work_autocancel() may fail, add return code check and
exit cw_bat_probe() on error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 0cb172a491 ("power: supply: cw2015: Use device managed API to simplify the code")
Signed-off-by: Ivan Abramov <i.abramov@mt-integration.ru>
Link: https://patch.msgid.link/20251008120711.556021-1-i.abramov@mt-integration.ru
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The device node pointers `np_conn` and `np_edev`, obtained from
of_parse_phandle() and of_get_parent() respectively, are not released.
This results in a reference count leak.
Add of_node_put() calls after the last use of these device nodes to
properly release their references and fix the leaks.
Fixes: 8242336dc8 ("power: supply: rt5033_charger: Add cable detection and USB OTG supply")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20250929113234.1726-1-vulab@iscas.ac.cn
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
MAX77705 charger is most likely always a single device on the board,
however nothing stops board designers to have two of them, thus same
device driver could probe twice. Or user could manually try to probing
second time.
Device driver is not ready for that case, because it allocates
statically 'struct regmap_irq_chip' as non-const and stores during
probe in 'irq_drv_data' member a pointer to per-probe state
container ('struct max77705_charger_data'). devm_regmap_add_irq_chip()
does not make a copy of 'struct regmap_irq_chip' but stores the pointer.
Second probe - either successful or failure - would overwrite the
'irq_drv_data' from previous device probe, so interrupts would be
executed in a wrong context.
Fixes: a6a494c8e3 ("power: supply: max77705: Add charger driver for Maxim 77705")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251023102905.71535-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add an entry for BD71828 charger driver.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/20250918-bd71828-charger-v5-3-851164839c28@kemnade.info
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add charger driver for ROHM BD718(15/28/78) PMIC charger block.
It is a stripped down version of the driver here:
https://lore.kernel.org/lkml/dbd97c1b0d715aa35a8b4d79741e433d97c562aa.1637061794.git.matti.vaittinen@fi.rohmeurope.com/
For the ease of review and to do a step-by-step approach remove all the
coloumb counter related stuff and do not sneak in BD71827 support. That
also avoids non-trivial rebasing of the above series.
Changes besides that:
Replace the custom property by a standard one and do not use megaohms
for the current sense resistor.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20250918-bd71828-charger-v5-2-851164839c28@kemnade.info
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The temperature is not from the die itself but from an NTC. That was
verified with an IR camera. Fix that.
Signed-off-by: Andreas Kemnade <akemnade@kernel.org>
Link: https://lore.kernel.org/r/20251027202847.119707-1-akemnade@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for dht20 temperature and humidity sensor from Aosong.
Modify aht10 driver to handle different init command for dht20 sensor by
adding init_cmd entry in the driver data. dht20 sensor is compatible with
aht10 hwmon driver with this change.
Tested on TI am62x SK board with dht20 sensor connected at i2c-2 port.
Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in>
Link: https://lore.kernel.org/r/2025112-94320-906858@bhairav-test.ee.iitb.ac.in
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In 2021, Maxim Integrated was acquired by Analog Devices.
maxim-ic.com & maximintegrated.com links redirect to analog.com.
Update maxim-ic.com & maximintegrated.com links to analog.com links.
Signed-off-by: Ankan Biswas <spyjetfayed@gmail.com>
Link: https://lore.kernel.org/r/20251017163501.11285-1-spyjetfayed@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In 2021, Maxim Integrated was acquired by Analog Devices.
maxim-ic.com & maximintegrated.com links redirect to analog.com.
Missing datasheets now available at Analog Devices added.
Signed-off-by: Ankan Biswas <spyjetfayed@gmail.com>
Link: https://lore.kernel.org/r/20251017161422.4404-1-spyjetfayed@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In 2021, Maxim Integrated was acquired by Analog Devices.
maxim-ic.com & maximintegrated.com links redirect to analog.com.
Broken redirects fixed to their proper analog.com links.
Fixes warnings in 'make linkcheckdocs'.
Signed-off-by: Ankan Biswas <spyjetfayed@gmail.com>
Link: https://lore.kernel.org/r/20251017154755.32105-1-spyjetfayed@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
CQ shadow area should not be updated at the end of a page (once every
64th CQ entry), except when CQ has no more CQEs. SW must also increase
the requested CQ size by 1 and make sure the CQ is not exactly one page
in size. This is to address a quirk in the hardware.
Signed-off-by: Jay Bhat <jay.bhat@intel.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251031021726.1003-4-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
In case we get an unsignaled error completion, we silently consume the CQE by
pretending the QP does not exist. Without this, bookkeeping for signaled
completions does not work correctly.
Signed-off-by: Jay Bhat <jay.bhat@intel.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251031021726.1003-5-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Failure to initialize info.create field to false in certain cases
was resulting in incorrect status code going to rdma-core when dereg_mr
failed during reset. To fix this, memset entire cqp_request->info
in irdma_alloc_and_get_cqp_request() function, so that this is not spread
all over the code.
Signed-off-by: Bhat, Jay <jay.bhat@intel.com>
Reviewed-by: Jacob Moroni <jmoroni@google.com>
Signed-off-by: Krzysztof Czurylo <krzysztof.czurylo@intel.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251031021726.1003-2-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Enforce local fence for LOCAL_INV WRs to
avoid spurious FASTREG_VALID_MKEY async events
during heavy invalidation/registration activity.
Signed-off-by: Jacob Moroni <jmoroni@google.com>
Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Link: https://patch.msgid.link/20251031021726.1003-3-tatyana.e.nikolova@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
The list operation to find and pop transaction entry appears several
times in transaction implementation, and can be replaced with a helper
functional macro.
Link: https://lore.kernel.org/r/20251101102131.925071-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
PCIe link configurations such as 8GT/s x2 and 16GT/s x1 may operate at the
same frequency, but differ in other characteristics like RPMh votes. But
the existing OPP selection which is solely based on frequency (the 'opp-hz'
DT property) cannot distinguish between such cases.
Hence, use the newly introduced dev_pm_opp_find_key_exact() API to match
both frequency and level (the 'opp-level' property) when selecting an OPP,
here level indicates PCIe data rate.
To support older device trees where opp-level is not defined, check if
opp-level is present or not using dev_pm_opp_find_level_exact(). If
not present fallback to frequency only match.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: zero initialize dev_pm_opp_key struct]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: add 'opp-hz' and 'opp-level' in commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251013-opp_pcie-v5-5-eb64db2b4bd3@oss.qualcomm.com
Split ->populate() implementation from ->init() code.
This decoupling will help for the further changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Split ->populate() implementation from ->init() code.
This decoupling will help for the further changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a convention in the kernel to avoid error messages
in the cases of -ENOMEM errors. Besides that, the idea behind
using struct_size() and other macros from overflow.h is
to saturate the size that the following allocation call will
definitely fail, hence the check and the error messaging added
in regcache_flat_init() are redundant. Remove them.
Acked-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Split ->populate() implementation from ->init() code.
This decoupling will help for the further changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the future changes we would like to change the flow of the cache handling.
Add ->populate() callback in order to prepare for that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The JC_SUBCMD_RATE_MAX_ATTEMPTS constant is currently set to 500.
In a worst-case scenario where all attempts consistently fail, this could
cause the loop to block for up to 60000 ms (500 * 60ms * 2, including the
additional retry after a timeout).
This change lowers the maximum potential blocking time to 3000 ms
(25 * 60ms * 2), improving system responsiveness and efficiency.
Signed-off-by: Willy Huang <willyhuang@google.com>
Reviewed-by: Daniel J. Ogorchock <djogorchock@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The Chromebook Pixel 2013 (Link)'s ec does not support the lightbar manual
suspend commands. As a result, attempting to suspend the device fails and
prints the following error:
cros-ec-lightbar cros-ec-lightbar.3.auto: PM: dpm_run_callback(): platform_pm_suspend returns -22
cros-ec-lightbar cros-ec-lightbar.3.auto: PM: failed to suspend: error -22
PM: Some devices failed to suspend, or early wake event detected
Check the return value of lb_manual_suspend_ctrl in cros_ec_lightbar_probe
and disable manual suspend control if -EINVAL is returned.
Signed-off-by: Brady Norander <bradynorander@gmail.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20251030195910.8625-2-bradynorander@gmail.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Append a newline to the sysfs_emit() output in tle62x0_gpio_show. This
aligns with common kernel conventions and improves readability for
userspace tools that expect newline-terminated values.
Signed-off-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Link: https://patch.msgid.link/20251030124755.1828434-1-zhongqiu.han@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Even Xu <even.xu@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The "bgpio" prefix is a historical left-over. We no longer use it in any
user-facing symbol. Let's drop it from the module's internals as well
and replace it with "gpio_mmio_".
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251027-gpio-mmio-refactor-v1-2-b0de7cd5a4b9@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Commit 6277a486a7 ("regulator: dt-bindings: Convert Dialog DA9211
Regulators to DT schema") converts the last txt dt-binding in DIALOG
SEMICONDUCTOR DRIVERS to the yaml format. With that, there is no file,
which matches the pattern for the dt-binding txt file entry in that
section. The existing yaml files are already covered by the file entry with
the pattern dlg,da9*.yaml.
Remove the obsolete file pattern in DIALOG SEMICONDUCTOR DRIVERS.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Link: https://patch.msgid.link/20251029081516.83298-1-lukas.bulwahn@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The standard flat cache did not contain any validity info, so the cache
was always considered to be entirely valid. Multiple mechanisms exist to
initialize the cache on regmap init (defaults, raw defaults, HW init),
but not all drivers are using one of these. As a result, their
implementation might currently depend on the zero-initialized cache or
contain other workarounds.
When reading an uninitialized value from the flat cache, warn the user,
but maintain the current behavior. This will allow developers to switch
to a sparse (flat) cache independently.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Link: https://patch.msgid.link/20251029081248.52607-3-sander@svanheule.net
Signed-off-by: Mark Brown <broonie@kernel.org>
The flat regcache will always assume the data in the cache is valid.
Since the cache is preferred over hardware access, this may shadow the
actual state of the device.
Add a new containing cache structure with the flat data table and a
bitmap indicating cache validity. REGCACHE_FLAT will still behave as
before, as the validity is ignored.
Define new cache type REGCACHE_FLAT_S: a flat cache with sparse
validity. The sparse validity is used to determine if a hardware access
should occur to initialize the cache on the fly, vs. at regmap init for
REGCACHE_FLAT. Contrary to REGCACHE_FLAT, this allows us to implement
regcache_ops.drop.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Link: https://patch.msgid.link/20251029081248.52607-2-sander@svanheule.net
Signed-off-by: Mark Brown <broonie@kernel.org>
caab002d50 ("PCI: brcmstb: Disable L0s component of ASPM if requested")
set PCI_EXP_LNKCAP_ASPM_L1 and (optionally) PCI_EXP_LNKCAP_ASPM_L0S in
PCI_EXP_LNKCAP (aka PCIE_RC_CFG_PRIV1_LINK_CAPABILITY in brcmstb).
But instead of using PCI_EXP_LNKCAP_ASPM_L1 and PCI_EXP_LNKCAP_ASPM_L0S
directly, it used PCIE_LINK_STATE_L1 and PCIE_LINK_STATE_L0S, which are
Linux-created values that only coincidentally matched the PCIe spec.
b478e162f2 ("PCI/ASPM: Consolidate link state defines") later changed
them so they no longer matched the PCIe spec, so the bits ended up in the
wrong place in PCI_EXP_LNKCAP.
Use PCI_EXP_LNKCAP_ASPM_L0S to clear L0s support when there's an
'aspm-no-l0s' property. Rely on brcmstb hardware to advertise L0s and/or
L1 support otherwise.
Fixes: caab002d50 ("PCI: brcmstb: Disable L0s component of ASPM if requested")
Reported-by: Bjorn Helgaas <bhelgaas@google.com>
Closes: https://lore.kernel.org/linux-pci/20250925194424.GA2197200@bhelgaas
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
[mani: reworded subject and description, added closes tag and CCed stable]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251003170436.1446030-1-james.quinlan@broadcom.com
The new common domain number allocator can replace the custom allocator
in VMD.
Beyond some code reuse benefits it does close a potential race whereby
vmd_find_free_domain() collides with new PCI buses coming online with a
conflicting domain number. Such a race has not been observed in practice,
hence not tagging this change as a fix.
As VMD uses pci_create_root_bus() rather than pci_alloc_host_bridge() +
pci_scan_root_bus_bridge() it has no chance to set ->domain_nr in the
bridge so needs to manage freeing the domain number on its own.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Szymon Durawa <szymon.durawa@linux.intel.com>
Cc: Nirmal Patel <nirmal.patel@linux.intel.com>
Link: https://patch.msgid.link/20251024224622.1470555-3-dan.j.williams@intel.com
The ability to emulate a host bridge is useful not only for hardware PCI
controllers like CONFIG_VMD, or virtual PCI controllers like
CONFIG_PCI_HYPERV, but also for test and development scenarios like
CONFIG_SAMPLES_DEVSEC [1].
One stumbling block for defining CONFIG_SAMPLES_DEVSEC, a sample
implementation of a platform TSM for PCI Device Security, is the need to
accommodate PCI_DOMAINS_GENERIC architectures alongside x86 [2].
In support of supplementing the existing CONFIG_PCI_BRIDGE_EMUL
infrastructure for host bridges:
* Introduce pci_bus_find_emul_domain_nr() as a common way to find a free
PCI domain number whether that is to reuse the existing dynamic
allocation code in the !ACPI case, or to assign an unused domain above
the last ACPI segment.
* Convert pci-hyperv to the new allocator so that the PCI core can
unconditionally assume that bridge->domain_nr != PCI_DOMAIN_NR_NOT_SET
is the dynamically allocated case.
A follow on patch can also convert vmd to the new scheme. Currently vmd is
limited to CONFIG_PCI_DOMAINS_GENERIC=n (x86) so, unlike pci-hyperv, it
does not immediately conflict with this new pci_bus_find_emul_domain_nr()
mechanism.
Link: http://lore.kernel.org/174107249038.1288555.12362100502109498455.stgit@dwillia2-xfh.jf.intel.com [1]
Reported-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Closes: http://lore.kernel.org/20250311144601.145736-3-suzuki.poulose@arm.com [2]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Link: https://patch.msgid.link/20251024224622.1470555-2-dan.j.williams@intel.com
The Intel DG cards do not have separate power control for
persistent memory.
The memory is available when the whole card is awake.
Enable runtime PM in mtd driver to notify parent graphics driver
that whole card should be kept awake while nvm operations are
performed through this driver.
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H616 nand controller has the same base as A10/A23, with some
differences:
- mdma is based on chained buffers
- its ECC supports up to 80bit per 1024bytes
- some registers layouts are a bit different, mainly due do the stronger
ECC.
- it uses USER_DATA_LEN registers along USER_DATA registers.
- it needs a specific clock for ECC and MBUS.
Introduce the basic support, with ECC and scrambling, but without
DMA/MDMA.
Tested on Whatsminer H616 board (with and without scrambling, ECC)
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H6/H616 the SRAM is bigger than the A10/A23 one, so move its size
into sunxi_nfc_caps.
No functional change
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H6/H616 error mask register is bigger than the A10/A23 one, so move
its mask into sunxi_nfc_caps.
No functional change
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H6/H616 spare area register is not at the same offset as the
A10/A23 one, so move its offset into sunxi_nfc_caps.
No functional change.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H6/H616 pattern ID register is not at the same offset as the
A10/A23 one, so move its offset into sunxi_nfc_caps.
No functional change.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H6/H616 RANDOM EN/DIRECTION masks are different from A10/A23.
So move the masks into sunxi_nfc_caps.
No functional change.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H6/H616 ECC_MODE field is not at the same offset, and has not the
same size.
So move the mask into sunxi_nfc_caps.
Also, introduce a non compile-time field_prep() because FIELD_PREP()
doesn't work with non compile-time constant.
No functional change.
Link: https://lore.kernel.org/all/cover.1761588465.git.geert+renesas@glider.be
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H616 controller can't handle 512 bytes ECC block size. The
NFC_ECC_BLOCK_512 bit disappeared in H6, and NDFC_RANDOM_EN took its
place.
So, add has_ecc_block_512 capability to only set this bit on SoC having
it.
No functional change.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
On H6/H616, the register ECC_PAT_FOUND is at its own address, and not
part of ECC status register.
So, introduce the pattern found register offset in sunxi_nfc_caps, along
with its mask.
Also, introduce a non compile-time field_get() because FIELD_GET() and
u32_get_bits() don't work with non compile-time constant.
No functional change.
Link: https://lore.kernel.org/all/cover.1761588465.git.geert+renesas@glider.be
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H6/H616 USER_DATA register is not at the same offset as the
A10/A23 one, so move its offset into sunxi_nfc_caps
No functional change.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H6/H616 ECC_ERR_CNT register is not at the same offset as the
A10/A23 one, so move its offset into sunxi_nfc_caps
No functional change.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
H6/H616 has more ECC strenghts than A10/A23.
Move the ECC strenghts array to sunxi_nfc_caps to make it ready for
H6/H616 support.
No functional change.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The user data length (4) used all over the code hard coded.
And sometimes, it's not that trivial to know that it's the user data
length and not something else.
Moreover, for the H6/H616 this value is no more fixed by hardware, but
could be modified.
Using a define here makes the code more readable.
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The register NFC_REG_ECC_CTL was read twice and the result was not used,
then a third time with a mask applied.
Removing those calls didn't change the behavior.
Tested on H616 SoC, scrambling enabled.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The H616 NAND controller is quite different from the A10 and A23 ones,
some registers offset changed, and some new one are introduced.
Also, the DMA handling is different (it uses chained descriptors)
So, introduce a new compatible to represent this version of the IP.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The driver calls gpiod_get_optional() in the probe function but
never calls gpiod_put() in the remove function or in the probe
error path. This leads to a GPIO descriptor resource leak.
The lpc32xx_mlc.c driver in the same directory handles this
correctly by calling gpiod_put() on both paths.
Add gpiod_put() in the remove function and in the probe error path
to fix the resource leak.
Fixes: 6b923db286 ("mtd: rawnand: lpc32xx_slc: switch to using gpiod API")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Add support for NV-DDR mode in the Cadence NAND controller driver.
Signed-off-by: Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Due to the custom handling and layouts of certain nand controllers this
validity check will always fail for certain layouts. The check
inherently depends on even chunk sizing and this is not always the
case.
Modify the check to only print a warning, instead of failing to
init the attached NAND. This allows various 8 bit and 12 ECC strength
layouts to be used.
Fixes: 68c18dae68 ("mtd: rawnand: marvell: add missing layouts")
Signed-off-by: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
This reverts commit e6a30d0c48.
This change resulted in the 8bit ECC layouts having the incorrect amount
of read/write chunks, the last spare bytes chunk would always be missed.
Fixes: e6a30d0c48 ("mtd: rawnand: marvell: fix layouts")
Signed-off-by: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Physmap supports minimal PM since commit 0bc448b49e ("mtd: maps:
physmap: Add minimal Runtime PM support"), so support it also when used
in DT configurations.
Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Merge series from Oleksij Rempel <o.rempel@pengutronix.de>:
This series adds input supply definitions for the NXP PCA9450 PMIC.
Some systems detect power events such as undervoltage before the PMIC.
To allow correct propagation of such events, each regulator must define
its upstream input supply. The first patch updates the devicetree
binding to document new *-supply properties, and the second patch adds
matching .supply_name entries in the driver.
Changes in this series:
- Document INL1, INB13, INB26 and INB45 supply properties
- Link all LDO and BUCK regulators to their corresponding input groups
Add MSI doorbell support to reduce latency between PCI host and EP.
Before this change:
ping 169.254.172.137
64 bytes from 169.254.172.137: icmp_seq=1 ttl=64 time=0.575 ms
64 bytes from 169.254.172.137: icmp_seq=2 ttl=64 time=1.80 ms
64 bytes from 169.254.172.137: icmp_seq=3 ttl=64 time=8.19 ms
64 bytes from 169.254.172.137: icmp_seq=4 ttl=64 time=2.00 ms
After this change:
ping 169.254.144.71
64 bytes from 169.254.144.71: icmp_seq=1 ttl=64 time=0.215 ms
64 bytes from 169.254.144.71: icmp_seq=2 ttl=64 time=0.456 ms
64 bytes from 169.254.144.71: icmp_seq=3 ttl=64 time=0.448 ms
Also, change the data type of 'epf_ntb::db' to 'atomic_64' as multiple
doorbell interrupts might trigger at the same time.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[mani: added 'pci_epf_' prefix to doorbell IRQ name, minor code cleanups]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251015-vntb_msi_doorbell-v6-4-9230298b1910@nxp.com
Add pci_epf_assign_bar_space() API to allow setting any MMIO address as
the BAR memory space, such as an MSI message base address.
This API also conforms to the BAR base address and size alignment
restrictions enforced by the PCI spec r6.0, sec 7.5.1.2.1.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[mani: removed unused epc var, reworded kdoc, comments and description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251015-vntb_msi_doorbell-v6-3-9230298b1910@nxp.com
Introduce pci_epf_get_required_bar_size() helper to get the required BAR
size and backing memory size. This helper will be used to set a fixed MMIO
address as the backing memory for a BAR.
Since this helper returns both BAR size and the aligned memory size, use
two parameters, 'bar_size' and 'aligned_mem_size' to avoid confusion.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[mani: renamed helper to pci_epf_get_required_bar_size(), reworded description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Link: https://patch.msgid.link/20251015-vntb_msi_doorbell-v6-2-9230298b1910@nxp.com
Rename the member 'epf_bar::aligned_size' to 'epf_bar::mem_size' to better
reflect its purpose. 'aligned_size' was misleading, as it actually
represents the backing memory size allocated for the BAR rather than the
aligned size.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Link: https://patch.msgid.link/20251015-vntb_msi_doorbell-v6-1-9230298b1910@nxp.com
There seems to be nothing preventing this driver from being compile
tested so enable that to increase build coverage.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
There seems to be nothing preventing this driver from being compile
tested so enable that to increase build coverage.
This also allows for compile testing of further Tegra drivers (e.g.
IOMMU driver).
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add supply_name entries for all PCA9450 regulators to describe their
respective input pin groups (INB13, INB26, INB45, INL1). This links each
buck and LDO to the upstream supply that powers its input group.
On some systems, power faults such as undervoltage are detected before
the PMIC itself. Defining supply relationships allows the regulator
framework to propagate such events properly through the dependency
chain.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://patch.msgid.link/20251027124415.989301-3-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
gpiolib want to get completely rid of static gpiobase allocation, so
switch to dynamic allocate GPIO base in byte mode, also can avoid
warning message:
[1.529974] gpio gpiochip0: Static allocation of GPIO base is deprecated,
use dynamic allocation.
Reported-by: Hongliang Wang <wanghongliang@loongson.cn>
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251023090346.1995894-1-zhoubinbin@loongson.cn
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The IOMMU core attaches each device to a default domain on probe(). Then,
every new "attach" operation has a fundamental meaning of two-fold:
- detach from its currently attached (old) domain
- attach to a given new domain
Modern IOMMU drivers following this pattern usually want to clean up the
things related to the old domain, so they call iommu_get_domain_for_dev()
to fetch the old domain.
Pass in the old domain pointer from the core to drivers, aligning with the
set_dev_pasid op that does so already.
Ensure all low-level attach fcuntions in the core can forward the correct
old domain pointer. Thus, rework those functions as well.
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The last gdev is the device that failed the __iommu_device_set_domain().
So, it doesn't need to be reverted, given it's attached to group->domain
already.
This is not a problem currently, since it's a simply re-attach. However,
the core will need to pass in the old domain to __iommu_device_set_domain
so the old domain pointers would be inconsistent between a failed device
and all its prior succeeded devices, as all the prior devices need to be
reverted.
Avoid the re-attach for the last gdev, by breaking before the revert.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The set_dev_pasid for a release domain never gets called anyhow. So, there
is no point in defining a separate release_domain from the blocked_domain.
Simply reuse the blocked_domain.
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Following a coming core change to pass in the old domain pointer into the
attach_dev op and its callbacks, exynos_iommu_identity_attach() will need
this new argument too, which the release_device op doesn't provide.
Instead, the core provides a release_domain to attach to the device prior
to invoking the release_device callback. Thus, simply use that.
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Since the core now takes care of the require_direct case for the release
domain, simply use that via the release_domain op.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Generally an IOMMU driver should leave the translation as BLOCKED until the
translation entry is probed onto a struct device. When the struct device is
removed, the translation should be put back to BLOCKED.
Drivers that are able to work like this can set their release_domain to the
blocking domain, and the core code handles this work.
The exception is when the device has an IOMMU_RESV_DIRECT region, in which
case the OS should continuously allow translations for the given range. And
the core code generally prevents using a BLOCKED domain with this device.
Continue this logic for the device release and hoist some open coding from
drivers. If the device has dev->iommu->require_direct and the driver uses a
BLOCKED release_domain, override it to IDENTITY to preserve the semantics.
The only remaining required driver code for IOMMU_RESV_DIRECT should preset
an IDENTITY translation during early IOMMU startup for those devices.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The Raspberry Pi drivers aren't useful on other architectures, so
only offer them on ARM and ARM64, except for build testing purposes.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Link: https://patch.msgid.link/20251027132219.2f3274f0@endymion
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for mt8189 MM IOMMUs.
Signed-off-by: Zhengnan Chen <zhengnan.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add support for mt8189 INFRA IOMMUs.
Signed-off-by: Zhengnan Chen <zhengnan.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add DL_WITH_MULTI_LARB flag to support the HW which connect with
multiple larbs. Prepare for mt8189. In mt8189, the display connect
with larb1 and larb2 at the same time. Thus, we should add link
between disp-dev with these two larbs.
Signed-off-by: Zhengnan Chen <zhengnan.chen@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
There are three iommu in total, namely MM_IOMMU, APU_IOMMU, INFRA_IOMMU,
Add bindings for them.
Signed-off-by: Zhengnan Chen <zhengnan.chen@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
folio_nr_pages() is a faster helper function to get the number of pages when
NR_PAGES_IN_LARGE_FOLIO is enabled.
Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
When a GSI MAD packet is sent on the QP, it will potentially be
retried CMA_MAX_CM_RETRIES times with a timeout value of:
4.096usec * 2 ^ CMA_CM_RESPONSE_TIMEOUT
The above equates to ~64 seconds using the default CMA values.
The cm_id_priv's refcount will be incremented for this period.
Therefore, the timeout value waiting for a cm_id destruction must be
based on the effective timeout of MAD packets. To provide additional
leeway, we add 25% to this timeout and use that instead of the
constant 10 seconds timeout, which may result in false negatives.
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Link: https://patch.msgid.link/20251021132738.4179604-1-haakon.bugge@oracle.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
The spi subsystem has tracing, which is very convenient when debugging
problems. Add tracing for spi-mem too so that accesses that skip the spi
subsystem can still be seen.
The format is roughly based on the existing spi tracing. We don't bother
tracing the op's address because the tracing happens while the memory is
locked, so there can be no confusion about the matching of start and
stop. The conversion of cmd/addr/dummy to an array is directly analogous
to the conversion in the latter half of spi_mem_exec_op.
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://patch.msgid.link/20251021144702.1582397-1-sean.anderson@linux.dev
Signed-off-by: Mark Brown <broonie@kernel.org>
When Root Complex (RC) triggers a Doorbell interrupt to Endpoint (EP), it
triggers the below warning in the EP:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:271
Call trace:
__might_resched+0x130/0x158
__might_sleep+0x70/0x88
mutex_lock+0x2c/0x80
pci_epc_get_msi+0x78/0xd8
pci_epf_test_raise_irq.isra.0+0x74/0x138
pci_epf_test_doorbell_handler+0x34/0x50
The BUG arises because the EP's pci_epf_test_doorbell_handler() which is
running in the hard IRQ context is making an indirect call to
pci_epc_get_msi(), which uses mutex inside.
To fix the issue, convert the hard IRQ handler to a threaded IRQ handler to
allow it to call functions that can sleep during bottom half execution.
Also, register the threaded IRQ handler with IRQF_ONESHOT to keep the
interrupt line disabled until the threaded IRQ handler completes execution.
Fixes: eff0c286aa ("PCI: endpoint: pci-epf-test: Add doorbell test support")
Signed-off-by: Bhanu Seshu Kumar Valluri <bhanuseshukumar@gmail.com>
[mani: reworded description a bit]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20251014024109.42287-1-bhanuseshukumar@gmail.com
The amlogic,axg-pcie binding was never enabled as the 'select' schema
expects a single compatible value, but the binding has a fallback
compatible. Fix the 'select' by adding a 'contains'. With this, several
errors in the clock and reset properties are exposed. Some of the names
aren't defined in the common DWC schema and the order of clocks entries
doesn't match .dts files.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251024011122.26001-1-robh@kernel.org
The module alias does not match the cell name defined in the MFD driver,
preventing automatic loading when the driver is built as a module. So fix
the module alias to ensure proper module auto-loading.
Fixes: 0ef2929a01 ("leds: Add AAEON UP board LED driver")
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251020-leds-upboard-fix-module-alias-v2-1-84ac5c3a1a81@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
On the MT8196 and MT6991 SoCs, the GPU power and frequency is controlled
by some integration logic, referred to as "MFlexGraphics" by MediaTek,
which comes in the form of an embedded controller running
special-purpose firmware.
This controller takes care of the regulators and PLL clock frequencies
to squeeze the maximum amount of power out of the silicon.
Add a binding which models it as a power domain.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Clang warns (or errors with CONFIG_WERROR=y / W=e):
drivers/hid/intel-ish-hid/ipc/ipc.c:935:36: error: cast from 'void (*)(struct workqueue_struct *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
935 | if (devm_add_action_or_reset(dev, (void (*)(void *))destroy_workqueue,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/device/devres.h:168:34: note: expanded from macro 'devm_add_action_or_reset'
168 | __devm_add_action_or_ireset(dev, action, data, #action)
| ^~~~~~
This warning is pointing out a kernel control flow integrity (kCFI /
CONFIG_CFI=y) violation will occur due to this function cast when the
destroy_workqueue() is indirectly called via devm_action_release()
because the prototype of destroy_workqueue() does not match the
prototype of (*action)().
Use a local function with the correct prototype to wrap
destroy_workqueue() to resolve the warning and CFI violation.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510190103.qTZvfdjj-lkp@intel.com/
Closes: https://github.com/ClangBuiltLinux/linux/issues/2139
Fixes: 0d30dae38f ("HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blocking")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Zhang Lixu <lixu.zhang@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Let's avoid updating the SD current limit when the maximum power is 200mA
(0.72W) or less, as this is already the default value for the SD card. In
this way we avoid sending an unnecessary command during initialization.
Signed-off-by: Avri Altman <avri.altman@sandisk.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
led_banks contains LED module number(s) that should be grouped into the
module bank. led_banks is 0-initialized.
By checking the led_banks entries for 0, un-set entries are detected.
But a 0-entry also indicates that LED module 0 should be grouped into the
module bank.
By only iterating over the available entries no check for unused entries
is required and LED module 0 can be added to bank.
Cc: stable@vger.kernel.org
Fixes: 242b81170f ("leds: lp50xx: Add the LP50XX family of the RGB LED driver")
Signed-off-by: Christian Hitz <christian.hitz@bbv.ch>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Link: https://patch.msgid.link/20251008123222.1117331-1-christian@klarinett.li
Signed-off-by: Lee Jones <lee@kernel.org>
Marking the qcom_spi_ecc_engine_ops_pipelined as const provides
memory protection by preventing accidental modification of critical
function pointers at runtime. It also enables memory optimization
by placing the structure in read-only sections and improves code safety
by explicitly documenting the design intent that these operations
should not change after initialization.
Signed-off-by: Can Peng <pengcan@kylinos.cn>
Link: https://patch.msgid.link/20251023024250.3181084-1-pengcan@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Node names are already and properly checked by the core schema. No need
to do it again.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251020060951.30776-10-wsa+renesas@sang-engineering.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for PMR735D PMIC voltage regulators which are present on
Kaanapali boards.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251023-pmr735d_regulator-v2-2-452e1b28cd38@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for PMR735D PMIC used on Kaanapali boards.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251023-pmr735d_regulator-v2-1-452e1b28cd38@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The backlight interfaces don't require anything from <linux/fb.h>, so
don't include it.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://patch.msgid.link/20251013105553.836715-1-tzimmermann@suse.de
Signed-off-by: Lee Jones <lee@kernel.org>
GPIO chips often have data input and output registers aliased to the
same offset. The output register is non-valitile and could in theory be
cached. The input register however is volatile by nature and hence
should not be cached, resulting in different requirements for reads and
writes.
The generic gpio chip implementation stores a shadow value of the pin
output data, which is updated and written to hardware on output data
changes in bgpio_set(), bgpio_set_set(). Pin input values are always
obtained by reading the aliased data register from hardware.
For gpio-regmap the situation is more complex as the output data could
be in multiple registers, but we can use the regmap cache to shadow the
output values when marking the data registers as non-volatile. By using
regmap_read_bypassed() we can still treat the input values as volatile,
irrespective of the regmap config. This ensures proper functioning of
writing the output register with regmap_write_bits(), which will then
use and update the cache only on data writes, gaining some performance
from the cached output values.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20251021142407.307753-3-sander@svanheule.net
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
GPIO chips often have data input and output fields aliased to the same
offset. Since gpio-regmap performs a value update before the direction
update (to prevent glitches), a pin currently configured as input may
cause regmap_update_bits() to not perform a write.
This may cause unexpected line states when the current input state
equals the requested output state:
OUT IN OUT
DIR ''''''\...|.../''''''
pin ....../'''|'''\......
(1) (2) (3)
1. Line was configurad as out-low, but is reconfigured to input.
External logic results in high value.
2. Set output value high. regmap_update_bits() sees the value is
already high and discards the register write.
3. Line is switched to output, maintaining the stale output config
(low) instead of the requested config (high).
By switching to regmap_write_bits(), a write of the requested output
value can be forced, irrespective of the read state. Do this only for
aliased registers, so the more efficient regmap_update_bits() can still
be used for distinct registers.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20251021142407.307753-2-sander@svanheule.net
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Switch to the generic PCI power management framework and remove legacy
callbacks like .suspend() and .resume(). With the generic framework, the
standard PCI related work like:
- pci_save/restore_state()
- pci_enable/disable_device()
- pci_set_power_state()
is handled by the PCI core and this driver should implement only gpio-bt8xx
specific operations in its respective callback functions.
Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20251016163618.1355923-1-vaibhavgupta40@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add power domain IDs for RV1126B SoC.
Add a new compatible because register fields have changed.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add support for the power controllers found in the MediaTek MT8196
Chromebook SoC.
This chip has three power controllers, two of which located in the
SCP subsystems (where one can be directly controlled and the other
can be controlled only through the HW Voter IP), and one located
in the Multimedia HFRP subsystem, controllable only through the HW
Voter IP.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Merge the mmc fixes for v6.18-rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.19.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The dw-mshc controller in the RK3506 is compatible to the one first found
in the RK3288 SoC, so add the RK3506 to the variant list.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Since the reliance on ARM-specific struct pci_sys_data was removed, this
driver can be compile-tested on other architectures.
While at it, make the help text a bit more generic, as some members of
the R-Car Gen2 family have a different number of internal PCI
controllers.
Fixes: 4a957563fe ("PCI: rcar-gen2: Convert to use modern host bridge probe functions")
Suggested-by: Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: add rcar-gen2 to subject]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://patch.msgid.link/00f75d6732eacce93f04ffaeedc415d2db714cd6.1759480426.git.geert+renesas@glider.be
Add MAINTAINERS entry for PF1550 PMIC.
Signed-off-by: Samuel Kayode <samuel.kayode@savoirfairelinux.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Link: https://patch.msgid.link/20251001-pf1550-v12-6-a3302aa41687@savoirfairelinux.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for the battery charger for pf1550 PMIC.
Signed-off-by: Samuel Kayode <samuel.kayode@savoirfairelinux.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Link: https://patch.msgid.link/20251001-pf1550-v12-5-a3302aa41687@savoirfairelinux.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for the onkey of the pf1550 PMIC.
Signed-off-by: Samuel Kayode <samuel.kayode@savoirfairelinux.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Link: https://patch.msgid.link/20251001-pf1550-v12-4-a3302aa41687@savoirfairelinux.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add regulator support for the pf1550 PMIC.
Signed-off-by: Samuel Kayode <samuel.kayode@savoirfairelinux.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Link: https://patch.msgid.link/20251001-pf1550-v12-3-a3302aa41687@savoirfairelinux.com
Signed-off-by: Lee Jones <lee@kernel.org>
There are 3 sub-devices for which the drivers will be added in
subsequent patches.
Signed-off-by: Samuel Kayode <samuel.kayode@savoirfairelinux.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Link: https://patch.msgid.link/20251001-pf1550-v12-2-a3302aa41687@savoirfairelinux.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add a DT binding document for pf1550 PMIC. This describes the core MFD
device along with its children: regulators, charger and onkey.
Signed-off-by: Samuel Kayode <samuel.kayode@savoirfairelinux.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Link: https://patch.msgid.link/20251001-pf1550-v12-1-a3302aa41687@savoirfairelinux.com
Signed-off-by: Lee Jones <lee@kernel.org>
Document the RPMh Power Domains on the Kaanapali Platform.
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This device is powered by an FT232H, which is very similar to the
FT2232H this driver was written for. The key difference is it has only
one MPSSE instead of two. As a result, it presents only one USB
interface to the system, which conveniently "just works" out of the box
with this driver.
The brik exposes only two GPIO lines which are hardware limited to only
be useful in one direction. As a result, I've restricted things on the
driver side to refuse to configure any other lines.
This device, unlike the sealevel device I wrote this driver for
originally, is hotpluggable, which makes for all sorts of weird
edgecases. I've tried my best to stress-test the parts that could go
wrong, but given the new usecase, more heads taking a critical look at
the teardown and synchronization bits on the driver as a whole would be
appreciated.
Signed-off-by: Mary Strodl <mstrodl@csh.rit.edu>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251014133530.3592716-5-mstrodl@csh.rit.edu
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Builds out a facility for specifying compatible lines directions and
labels for MPSSE-based devices.
* dir_in/out are bitmask of lines that can go in/out. 1 means
compatible, 0 means incompatible.
* names is an array of line names which will be exposed to userspace.
Also changes the chip label format to include some more useful
information about the device to help identify it from userspace.
Signed-off-by: Mary Strodl <mstrodl@csh.rit.edu>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251014133530.3592716-4-mstrodl@csh.rit.edu
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
When an IRQ worker is running, unplugging the device would cause a
crash. The sealevel hardware this driver was written for was not
hotpluggable, so I never realized it.
This change uses a spinlock to protect a list of workers, which
it tears down on disconnect.
Signed-off-by: Mary Strodl <mstrodl@csh.rit.edu>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251014133530.3592716-3-mstrodl@csh.rit.edu
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Not sure how I missed this, but errors encountered when setting the
direction to input weren't being propagated to the caller.
Signed-off-by: Mary Strodl <mstrodl@csh.rit.edu>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251014133530.3592716-2-mstrodl@csh.rit.edu
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Merge the mmc fixes for v6.18-rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.19.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
An error code was assigned to a variable and checked accordingly.
This value was passed to a dev_err_probe() call in an if branch.
This function is documented in the way that the same value is returned.
Thus delete a redundant variable reassignment.
The source code was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use dma_set_mask_and_coherent() instead. No functional changes.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Added support to save and restore registers that are critical
during PM.
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Added "brcm,bcm74371-sdhci" compatibility to the controller driver.
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Clear SDIO_1_CFG_OP_DLY register when using HS200 mode to be
compliant with timing spec. We only need this for on BCM72116
SoCs.
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Moving SDIO_CFG_CQ_CAPABILITY register defines to be in sorted order for
better readability.
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Updating compatibility to support BCM72116 and BCM74371 SD host controller
similar to other settop SoCs.
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Document the compatible string for the SDHCI controller on the
sm8750 platform.
Signed-off-by: Sarthak Garg <sarthak.garg@oss.qualcomm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
As stated in Documentation/dev-tools/checkpatch.rst, octal file
permissions are preferred over symbolic constants because they are
easier to read and understand. Replace symbolic permissions with
their octal equivalents.
Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Document the compatible string for the SDHCI controller on the
Kaanapali platform.
Signed-off-by: Manish Pandey <manish.pandey@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
R-Car Gen2 SoCs have a 32 bit dataport, V3M even 64 bit. Make use of
the bigger size in the rare case DMA is failing.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc_sd_num_wr_blocks() is in the block error path.
It needs to use GFP_NOIO. There is no need to complicate
anything here.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Many distributions disable FW_LOADER_USER_HELPER, and this configuration
makes lp55xx LEDs completely unusable. Enable their use by only implying
the user helper, since the basic LEDs and the hardware patterns can be used
with only the sysfs interface.
Tested on Nokia N900 with LP5523.
Additionally do not refer to the sysfs interface as legacy anymore, since
it might be the only one available to users.
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Add default-brightness property to leds/common.yaml to establish a single
canonical definition for LED brightness initialization.
The property is currently defined locally in leds/leds-pwm.yaml and is
needed by auxdisplay/titanmec,tm16xx.yaml. Properties should be defined
in only one location to avoid type inconsistencies across bindings.
Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
fwnode_get_next_child_node() is now the same as
fwnode_get_next_available_child_node() on all backends (OF, ACPI and
swnode). In order to remove the available variants, switch the uses to
non-available variants (device_get_next_child_node() in this case).
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Lee Jones <lee@kernel.org>
fwnode_for_each_child_node() is now the same as
fwnode_for_each_available_child_node() on all backends (OF, ACPI and
swnode). In order to remove the available variants, switch the uses to
non-available variants.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Convert the ArcticSand arc2c0608 LED driver to the dt-schema.
Signed-off-by: Harrison Carter <hcarter@thegoodpenguin.co.uk>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Lee Jones <lee@kernel.org>
This driver no longer uses any symbols from the GPIOLIB internal header.
We can now drop the gpiolib.h include.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Link: https://lore.kernel.org/r/20251016-aspeed-gpiolib-include-v1-3-31201c06d124@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reading the GPIO hardware number from a descriptor is a valid use-case
outside of the GPIO core. Export the symbol to consumers of GPIO
descriptors.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Link: https://lore.kernel.org/r/20251016-aspeed-gpiolib-include-v1-2-31201c06d124@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This function takes a GPIO descriptor as first argument. Make its naming
consistent with the rest of the GPIO codebase and use the gpiod_ prefix.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Link: https://lore.kernel.org/r/20251016-aspeed-gpiolib-include-v1-1-31201c06d124@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
A kernel module must have a license and should have a description. Add
missing MODULE_LICENSE(), MODULE_DESCRIPTION() and throw in a
MODULE_AUTHOR() for good measure.
This fixes the following build issues:
ERROR: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-qixis-fpga.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpio/gpio-qixis-fpga.o
Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://lore.kernel.org/all/aPJW8HIke5pj3doX@sirena.org.uk/
Fixes: e88500247d ("gpio: add QIXIS FPGA GPIO controller")
Link: https://lore.kernel.org/r/20251020072028.21423-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add support for the second PCIe Root Complex present on Airoha AN7583
SoC.
This is based on the Mediatek Gen1/2 PCIe driver and similar to Gen3
also require workaround for the reset signals.
Introduce a new quirk to skip having to reset signals and also introduce
some additional logic to configure the PBUS registers required for Airoha
SoC.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251020111121.31779-6-ansuelsmth@gmail.com
Use the generic PCI MACRO for TPVPERL delay to wait for clock and power
stabilization after PERST# Signal instead of the raw value of 100 ms.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251020111121.31779-5-ansuelsmth@gmail.com
To clean Mediatek SoC PCIe struct, convert all the bool to a bitmap and
use a single quirks to reference all the values. This permits cleaner
addition of new quirk without having to define a new bool in the struct.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251020111121.31779-4-ansuelsmth@gmail.com
Introduce Airoha AN7583 SoC compatible in mediatek PCIe controller
binding.
Similar to GEN3, the Airoha AN7583 GEN2 PCIe controller require the
PBUS csr property to permit the correct functionality of the PCIe
controller.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251020111121.31779-3-ansuelsmth@gmail.com
Convert the PCI mediatek Documentation to YAML schema to enable
validation of the supported GEN1/2 Mediatek PCIe controller.
While converting, lots of cleanup were done from the .txt with better
specifying what is supported by the various PCIe controller variant and
drop of redundant info that are part of the standard PCIe Host Bridge
schema.
To reduce schema complexity the .txt is split in 2 YAML, one for
mt7623/mt2701 and the other for every other compatible.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251020111121.31779-2-ansuelsmth@gmail.com
Fix 49 kernel-doc warnings in ib_verbs.h:
- Add struct short description for rdma_stat_desc, rdma_hw_stats.
- Fix kernel-doc format for struct members (use ':' instead of '-') for
several structs.
- Don't use "/**" kernel-doc notation for struct members in ib_device_ops
(most members are not documented and most of the kernel-doc was
not formatted correctly).
- Spell function parameters correctly in ib_dma_map_sgtable_attrs(),
ib_device_try_get(), rdma_roce_rescan_device().
- Add kernel-doc for the function parameter in
rdma_flow_label_to_udp_sport().
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20251020034320.3011094-1-rdunlap@infradead.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
When returning from read_config_rom() function, the allocated buffer and
the previous buffer for configuration ROM should be released. The cleanup
function is useful in the case.
This commit uses the cleanup function to remove goto statements.
Link: https://lore.kernel.org/r/20251020115810.92839-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In the main loop of mvebu_gpio_irq_handler() some calls to
irq_find_mapping() can be saved.
There is no point to find an irq number before checking if this something
has to be done.
By testing first, some calls can be saved.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/7190f5def0489ed3f40435449c86cd7c710e6dd4.1760862679.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The probe messages currently print "using AI" and "using no AI",
which can be confusing to users unfamiliar with the datasheet term.
Clarify these by spelling out "auto increment", which is the meaning
of the AI bit described in the register map.
No functional change, only clearer log wording and matching comment
update.
Signed-off-by: Michael Roth <mail@mroth.net>
Link: https://lore.kernel.org/r/20251018101404.3630905-1-mail@mroth.net
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
devm_pm_runtime_enable() is used in the probe, so pm_runtime_disable()
should not be called explicitly in the remove function.
Fixes: 1c72774df0 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Tested-by: Chen Wang <unicorn_wang@outlook.com> # on Pioneerbox.
Acked-by: Chen Wang <unicorn_wang@outlook.com>
Link: https://patch.msgid.link/242eca0ff6601de7966a53706e9950fbcb10aac8.1759169586.git.christophe.jaillet@wanadoo.fr
The variable page_offset is being assigned a value at the start of
a loop and being redundantly zero'd at the end of the loop, there
is no code that reads the zero'd value. The assignment is redundant
and can be removed.
Signed-off-by: Colin Ian King <coking@nvidia.com>
Link: https://patch.msgid.link/20251014120343.2528608-1-coking@nvidia.com
Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
rdma_accept() also has this, so this is now more consistent and may
prevent bugs in future.
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: linux-rdma@vger.kernel.org
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Link: https://patch.msgid.link/20251008165913.444276-1-metze@samba.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
hook_fault_code() is an ARM32-specific API. Guard it and related code with
CONFIG_ARM #ifdefs and remove the ARM arch dependency from Kconfig so the
driver can be compile tested on other architectures.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
[mani: dropped the ARM arch Kconfig dependency]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linar.org>
Link: https://patch.msgid.link/20250925202738.2202195-1-helgaas@kernel.org
On the Qualcomm Kaanapali platform the PCIe host is compatible with the
DWC controller present on the SM8550 platform.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251015-kaanapali-pcie-upstream-v2-1-84fa7ea638a1@oss.qualcomm.com
Replace manual get/enable logic with devm_regulator_get_enable_optional()
to reduce boilerplate and improve error handling. This devm helper ensures
the regulator is enabled during probe and automatically disabled when the
platform device is freed.
Also drop the redundant 'rockchip_pcie::vpcie3v3' pointer.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250905112736.6401-1-linux.amoon@gmail.com
TASCAM FW-1884/FW-1804/FW-1082 have a quirk that they often freeze when
receiving isochronous packets at S400. This behaviour is suppressed by a
new quirk flag added in Linux FireWire core to restrict maximum speed.
Consequently both of the asynchronous transactions and isochronous
transmissions are done at S200. However, the device still transfers
isochronous packet at S400, and the way to indicate the transmission
speed is not cleared yet.
This commit correctly reserves isochronous resources for the transferred
packet stream at S400. As a beneficial side effect, the pair of
isochronous transmissions for FW-1884 fits within the bandwidth capacity
of the bus.
Link: https://lore.kernel.org/r/20251018035532.287124-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
TASCAM FW-1884/FW-1804/FW-1082 is too lazy to repspond to asynchronous
request at S400. The asynchronous transaction often results in timeout.
This is a problematic quirk.
This commit adds support for the quirk. When identifying the new quirk
flag, then the transaction speed is configured at S200.
Link: https://lore.kernel.org/r/20251018035532.287124-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Current implementation determines the maximum transaction speed supported
by the target device after reading bus information block of configuration
ROM. The read operations for root directory block are then performed at
the determined speed. However, some devices have quirks that cause issues
when transactions are performed at the determined speed.
In the first place, all devices are required to support the lowest speed
(S100) and must respond successfully to any read request within the
configuration ROM space. Therefore it is safe to postpone speed
determination until the entire configuration ROM has been read.
This commit moves the speed determination after reading root directory.
Link: https://lore.kernel.org/r/20251018035532.287124-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
The platform_get_resource() function doesn't return error pointers, it
returns NULL on error. Update the error checking to match.
Fixes: 64d87ccfae ("spi: aspeed: Only map necessary address window region")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aPJpEnfK31pHz8_w@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
The same suspend and resume callbacks are used for both suspend-to-RAM/idle
and hibernation. These callbacks invoke pm_suspend_via_firmware() and
pm_resume_via_firmware(), respectively. In the .freeze() of hibernation,
pm_suspend_via_firmware() returns false, causing the driver to put ISH into
D0i3. However, during the .thaw(), pm_resume_via_firmware() returns true,
leading the driver to treat ISH as resuming from D3 instead of D0i3. The
asymmetric behavior between .freeze() and .thaw() during hibernation can
cause the client connection states on the firmware side and the driver side
to become inconsistent.
To address the inconsistent client connection states issue, separate
hibernate-related callbacks (freeze, thaw) in dev_pm_ops. Since ISH does
not need to save any firmware-related state when entering hibernation, it
is sufficient to call pci_save_state() in .freeze() to prevent the PCI bus
from changing the ISH power state. No actions are required in .thaw().
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
On ISH power-up, the bootloader enters sleep after preparing to load the
main firmware, waiting for the driver to be ready. When the driver is
ready, it sends a void message to wake up the bootloader and load the main
firmware. The main firmware then sends MNG_RESET_NOTIFY to the driver for
handshake.
This void message-based IPC handshake only works if the main firmware has
not been loaded. During hibernation resume, if the restore kernel has the
ISH driver, the driver wakes up the bootloader to load the main firmware
and perform IPC handshake. However, when switching to the image kernel,
since the main firmware is already loaded, sending a void message in the
.restore() callback does not trigger IPC handshake.
By sending MNG_RESET_NOTIFY (IPC RESET message) in ish_wakeup() instead of
a void message, we can explicitly wake up the bootloader and perform IPC
handshake, regardless of the firmware state. Additionally, since
ish_ipc_reset() already waits for recvd_hw_ready, the redundant wait for
recvd_hw_ready in ish_hw_start() is removed.
The timeout for waiting for HW ready is set to 10 seconds, matching the
original timeout value used in ish_wakeup(), to ensure reliable wakeup on
hardware that requires more time, such as the Lenovo ThinkPad X1 Titanium
Gen 1.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Both ISH firmware and driver can actively send MNG_RESET_NOTIFY to initiate
an FW reset handshake. Upon receiving this, the peer should reply with
MNG_RESET_NOTIFY_ACK. Therefore, the driver should schedule the FW reset
handshake work function when receiving either MNG_RESET_NOTIFY or
MNG_RESET_NOTIFY_ACK.
Previously, driver only scheduled the work function on MNG_RESET_NOTIFY.
This patch ensures the work function is scheduled on both messages, but
only replies with MNG_RESET_NOTIFY_ACK when receiving MNG_RESET_NOTIFY.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
When ISH resumes from D3, the connection between ishtp clients and firmware
is lost. The ish_resume() function schedules resume_work asynchronously to
re-initiate the connection and then returns immediately. This can cause a
race where the upper-layer ishtp client driver's .resume() may execute
before the connection is fully restored, leaving the client in a stale
connected state. If the client sends messages during this window, the
firmware cannot respond.
To avoid this, reset the ishtp clients' state before returning from
ish_resume() if ISH is resuming from D3.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
When resuming from suspend-to-RAM or hibernate, the ISH firmware is powered
on from D3, causing all previous client connections between the firmware
and driver to be lost. Although the underlying ishtp bus driver initiates a
client reconnection flow, this process is asynchronous. As a result, when
hid_ishtp_cl_resume_handler() is executed, the connection may not have been
re-established yet. Clearing the suspended flag prematurely in this
scenario can lead to a timeout when the upper-layer HID sensor driver set
feature during resume.
To prevent such timeouts, only clear the suspended flag after confirming
that the connection state is ISHTP_CL_CONNECTED.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Add the ishtp_get_connection_state() function for struct ishtp_cl, allowing
ishtp client drivers to retrieve the current connection state.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
During suspend/resume tests with S2IDLE, some ISH functional failures were
observed because of delay in executing ISH resume handler. Here
schedule_work() is used from resume handler to do actual work.
schedule_work() uses system_wq, which is a per CPU work queue. Although
the queuing is not bound to a CPU, but it prefers local CPU of the caller,
unless prohibited.
Users of this work queue are not supposed to queue long running work.
But in practice, there are scenarios where long running work items are
queued on other unbound workqueues, occupying the CPU. As a result, the
ISH resume handler may not get a chance to execute in a timely manner.
In one scenario, one of the ish_resume_handler() executions was delayed
nearly 1 second because another work item on an unbound workqueue occupied
the same CPU. This delay causes ISH functionality failures.
A similar issue was previously observed where the ISH HID driver timed out
while getting the HID descriptor during S4 resume in the recovery kernel,
likely caused by the same workqueue contention problem.
Create dedicated unbound workqueues for all ISH operations to allow work
items to execute on any available CPU, eliminating CPU-specific bottlenecks
and improving resume reliability under varying system loads. Also ISH has
three different components, a bus driver which implements ISH protocols, a
PCI interface layer and HID interface. Use one dedicated work queue for all
of them.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver does not perform any locking, does not execute or use any sleep
related functionality, and does not allocate memory. Drop the unnecessary
include files.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver does not perform any locking, does not execute or use any sleep
related functionality, and does not allocate memory. Drop the unnecessary
include files.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver does not perform any locking and thus does not need to
include mutex.h. Drop the unnecessary include file.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
During writing, the entire flash page (including OOB) will be updated
with the values from the temporary buffer, so we need to fill the
untouched areas of the buffer with 0xff value to prevent accidental
data overwriting.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251012121707.2296160-14-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
The spinand driver do 3 type of dirmap requests:
* read/write whole flash page without oob
(offs = 0, len = page_size)
* read/write whole flash page including oob
(offs = 0, len = page_size + oob_size)
* read/write oob area only
(offs = page_size, len = oob_size)
The trick is:
* read/write a single "sector"
* set a custom sector size equal to offs + len. It's a bit safer to
rounded up "sector size" value 64.
* set the transfer length equal to custom sector size
And it works!
Thus we can remove a dirty hack that reads flash page settings from
SNFI registers during driver startup. Also airoha_snand_adjust_op_size()
function becomes unnecessary.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Link: https://patch.msgid.link/20251012121707.2296160-13-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Set custom sector size equal to flash page size including oob. Thus we
will always read a single sector. The maximum custom sector size is
8187, so all possible flash sector sizes are supported.
This patch is a necessary step to avoid reading flash page settings
from SNFI registers during driver startup.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251012121707.2296160-12-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
This just reduce the number of modification of REG_SPI_NFI_CNFG and
REG_SPI_NFI_SECCUS_SIZE registers during dirmap operation.
This patch is a necessary step to avoid reading flash page settings
from SNFI registers during driver startup.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251012121707.2296160-11-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
spi-airoha-snfi uses custom sector size in REG_SPI_NFI_SECCUS_SIZE
register, so setting of page/oob sizes in REG_SPI_NFI_PAGEFMT is not
required.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Link: https://patch.msgid.link/20251012121707.2296160-10-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Airoha snfi spi controller supports acceleration of DUAL/QUAD
operations, but does not supports DUAL_IO/QUAD_IO operations.
Luckily DUAL/QUAD operations do the same as DUAL_IO/QUAD_IO ones,
so we can issue corresponding DUAL/QUAD operation instead of
DUAL_IO/QUAD_IO one.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251012121707.2296160-9-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
The code switches to dma at the start of dirmap operation and returns
to non-dma at the end of dirmap operation, so an additional switch to
non-dma at the start of dirmap write is not required.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251012121707.2296160-5-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
The "length < 160" restriction is not needed because airoha_snand_write_data()
and airoha_snand_read_data() will properly handle data transfers above
SPI_MAX_TRANSFER_SIZE.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251012121707.2296160-3-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>:
This series contains patches to update rpmh-regulator driver and
dt-bindings for supporting the PMIC voltage regulators present on the
boards with Qualcomm's next gen compute SoC - Glymur.
Device tree changes aren't part of this series and will be posted
separately after the official announcement of the Glymur SoC.
This patch fixes warnings in Documentation/hwmon/lm90.rst reported when
running 'make linkcheckdocs'.
On 2011-09-23 National Semiconductors became part of Texas Instruments
and national.com is no longer accessible. The datasheet resources for
the chips are now available at Texas Instruments website and have been
updated for lm90.
In 2021, Maxim Integrated was acquired by Analog Devices and maxim-ic.com
redirects to analog.com. The chip datasheets are now available at
Analog Devices and have been updated accordingly.
Some additional broken or unavailable links have been replaced with
equivalents hosted by DigiKey.
Signed-off-by: Ankan Biswas <spyjetfayed@gmail.com>
Link: https://lore.kernel.org/r/20251016103049.2573-1-spyjetfayed@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for the ADT7422 high accuracy digital temperature sensor. It's
identical to the other chips supported in the driver so we just need to
add it to the ID tables.
Co-developed-by: Cosmin Tanislav <demonsingur@gmail.com>
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20251015-dev-add-adt7422-v1-3-7cf72d3253ad@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add a struct of_device_id match table to the driver.
While at it, make sure to properly include mod_devicetable.h which is
also needed for struct i2c_device_id.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20251015-dev-add-adt7422-v1-2-7cf72d3253ad@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Last user of linux/gpio/legacy-of-mm-gpiochip.h is gone.
Remove linux/gpio/legacy-of-mm-gpiochip.h and
CONFIG_OF_GPIO_MM_GPIOCHIP
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Remove legacy-of-mm-gpiochip.h header file. The above mentioned
file provides an OF API that's deprecated. There is no agnostic
alternatives to it and we have to open code the logic which was
hidden behind of_mm_gpiochip_add_data(). Note, most of the GPIO
drivers are using their own labeling schemas and resource retrieval
that only a few may gain of the code deduplication, so whenever
alternative is appear we can move drivers again to use that one.
[Text copied from commit 34064c8267 ("powerpc/8xx: Drop
legacy-of-mm-gpiochip.h header")]
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Extend the existing Tegra186 GPIO controller driver with support for
the GPIO controller found on Tegra410. Tegra410 supports two GPIO
controllers referred to as 'COMPUTE' and 'SYSTEM'.
Co-developed-by: Nathan Hartman <nhartman@nvidia.com>
Signed-off-by: Nathan Hartman <nhartman@nvidia.com>
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Introduce a generic macro TEGRA_GPIO_PORT to define SoC specific
ports macros. This simplifies the code and avoids unnecessary
duplication.
Suggested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The latched input feature of the pca953x GPIO controller is useful
when an input is configured to trigger interrupts on rising or
falling edges, because it allows retrieving which edge type caused
a given interrupt even if the pin state changes again before the
interrupt handler has a chance to run. But for level-triggered
interrupts, reading the latched input state can cause an active
interrupt condition to be missed, e.g. if an active-low signal (for
which an IRQ_TYPE_LEVEL_LOW interrupt has been configured) triggers
an interrupt when switching to the inactive state, but then becomes
active again before the interrupt handler has a chance to run: in
this case, if the interrupt handler reads the latched input state,
it will wrongly assume that the interrupt is not pending.
Fix the above issue by enabling the latch only on edge-triggered
inputs, instead of all interrupt-enabled inputs.
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
Reviewed-by: Ian Ray <ian.ray@gehealthcare.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add support for the GPIO controller found on some QIXIS FPGAs in
Layerscape boards such as LX2160ARDB and LS1046AQDS. This driver is
using gpio-regmap.
A GPIO controller has a maximum of 8 lines (all found in the same
register). Even within the same controller, the GPIO lines' direction is
fixed, which mean that both input and output lines are found in the same
register. This is why the driver also passed to gpio-regmap the newly
added .fixed_direction_output bitmap to represent the true direction of
the lines.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Michael Walle <mwalle@kernel.org> # for the gpio-regmap part
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
There are GPIO controllers such as the one present in the LX2160ARDB
QIXIS FPGA which have fixed-direction input and output GPIO lines mixed
together in a single register. This cannot be modeled using the
gpio-regmap as-is since there is no way to present the true direction of
a GPIO line.
In order to make this use case possible, add a new configuration
parameter - fixed_direction_output - into the gpio_regmap_config
structure. This will enable user drivers to provide a bitmap that
represents the fixed direction of the GPIO lines.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add a device tree binding for the QIXIS FPGA based GPIO controller.
Depending on the board, the QIXIS FPGA exposes registers which act as a
GPIO controller, each with 8 GPIO lines of fixed direction.
Since each QIXIS FPGA layout has its particularities, add a separate
compatible string for each board/GPIO register combination supported.
Since these GPIO controllers are trivial, make use of the newly added
trivial-gpio.yaml file instead of creating an entirely new one.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Initialize input regulator and gpios to proper values to have things
basically working as well as in the case when these things are
hardwired.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Andreas Kemnade <akemnade@kernel.org>
Link: https://patch.msgid.link/20250917-sy7636-rsrc-v3-2-331237d507a2@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for PMH0101/PMCX0102/PMH0110/PMH0104 PMIC voltage
regulators which are present on Glymur boards.
Introduce new LDOs & SMPSs under them (PMIC5 subtype 530 for
both).
For these new LDOs support a new optimum power mode(OPM). In
this mode LDO will automatically switch between high power mode
(HPM) and low power mode (LPM) based on the real-time LDO load
current. Its operation is analogous to SMPS AUTO mode.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Co-developed-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-4-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently rpmh-regulator resource name inside CMD-DB follows this
format: `^(ldo|smp|bob|vs)[a-n][1-9][0-9]?$`
(eg - ldob11, smpa2, bobc1 etc)
Here `[a-n]` in the resource name signifies the `pmic-id`.
However, newer firmware follows a different format that also
includes the `bus_id` as well in the resource name.
New format:
`^(L|S|B)[1-9][0-9]?[A-N]_E[0-3]$`
(eg - L11B_E1, S2A_E0, B1C_E0 etc)
Here `_E[0-3]` at the end is the `bus_id`, and upper case `[A-N]`
is used to denote `pmic-id`, while the regulator `(ldo|smp|bob)`
is replaced with their initials in upper case `(L|S|B|VA)`.
To handle this properly, do the following:
- Remove the `resource_name` member from vreg init data
- Add `index` and `regulator_hw_type` new members, which will
contain the index number and the regulator hardware type
(SMPS/LDO/BOB/VS) which can be combined with the pmic-id read
from the devicetree to generate the resource_name.
- Choose new resource name format if `pmic-id` contains `_E`
in it, else fallback to old format.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-3-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, CMD-DB names for RPMH regulators follow this format:
`^(smps|ldo|bob|vs)[a-n][1-9][0-9]?$`
Here, the `[a-n]` value is read from the `pmic-id` DT property,
which is unique to each PMIC present on the board.
Note that in this older CMD-DB name format the SPMI bus on which
a particular PMIC regulator exists was not apparent from its
CMD-DB name.
New targets like Glymur, where we have multiple SPMI buses,
overcome this limitation by following a new CMD-DB name format:
`^(L|S|B)[1-9][0-9]?[A-N]_E[0-3]$`
Here `[A-N]_E[0-3]` part will now be read from the `pmic-id` DT
prop and it includes the SPMI bus id `[0-3]` as well.
However, the PMIC ID part `[A-N]` of the CMD-DB name is now
unique only to the SPMI bus that the PMIC regulator is present
on. which means `L1B_E0` and `L1B_E1` are both possible CMD-DB
names for two different regulator LDOs present on two different
SPMI buses (bus id 0 and 1) on the same board.
Note that since the new `pmic-id` DT property is a combo of
PMIC ID and SPMI bus ID, so its still unique to each PMIC
present on the board.
Update the `pmic-id` property pattern information to reflect this
change in the driver handling to support this new CMD-DB naming
format while maintaining backward compatiblilty with old CMD-DB
naming format which is still supported for older/existing
targets.
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-2-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add rpmh-regulator driver compatibles strings for below PMICs:
- PMH0101
- PMH0104
- PMH0110
- PMCX0102
Also add the supply name properties for the regulators
present on these PMICs.
Co-developed-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-1-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SCMI specification states that SENSOR_CONFIG_SET is used to
enable/disable the sensors. The sensors can be disabled by default,
which is the case at least on NXP i.MX95. Explicitly trigger the
SENSOR_CONFIG_SET to enable the sensors, otherwise sensor read may
fail and won't return valid data.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Link: https://lore.kernel.org/r/20251015114953.148706-1-marek.vasut@mailbox.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver does not perform any locking and does not create sysfs
attributes. Drop the unnecessary include files.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
While at it, drop unnecessary include of hwmon-sysfs.c.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver does not perform any locking and does not create sysfs
attributes. Drop the unnecessary include files.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver does not perform any locking, does not sleep or check the time,
and does not create sysfs attributes. Drop the unnecessary include files.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
While at it, drop the unnecessary include of hwmon-sysfs.h.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking n the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for mp9945 device from Monolithic Power Systems, Inc.
(MPS) vendor. This is a single phase digital step down converter.
Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com>
Link: https://lore.kernel.org/r/20251009205458.396368-2-chou.cosmo@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use the energy64 attribute type instead of a locally defined sysfs
attribute to report the accumulated energy.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20251012211625.533791-2-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use the energy64 attribute type instead of a locally defined sysfs
attribute to report the accumulated energy.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20251012211625.533791-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support to read DTS for reading Intel Emerald Rapids platform.
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20251006215321.5036-4-fr0st61te@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Extend the functionality of hwmon (peci/dimmtemp) for Emerald Rapids
platform.
The patch has been tested on a 5S system with 16 DIMMs installed.
Verified read of DIMM temperature thresholds & temperature.
Using Sapphire's callbacks about getting thresholds because it's same
platform/socket.
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20251006215321.5036-3-fr0st61te@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for detection of Intel Emerald Rapids processor based on
CPU model.
Emerald Rapids Xeon processors with the model set to
INTEL_EMERALDRAPIDS_X. The data field for this entry is "emr".
Tested the patch series with AST2600 BMC with 5S Intel Emerald Rapids
processors & verified by reading cpu & dimm temperature which matches
host sensor values from lmsensors.
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20251006215321.5036-2-fr0st61te@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The board has a similar sensor configuration as the ROG STRIX X870E-E
GAMING WIFI, with an additional temperature sensor header.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20251003081002.1013313-3-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
ADPM12200 is a quarter brick DC/DC Power Module. It is a high power
non-isolated converter capable of delivering regulated 12V with
continuous power level of 2000W. Uses PMBus.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Link: https://lore.kernel.org/r/20251001-hwmon-next-v1-2-f8ca6a648203@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Since fan properties can include reg, the fan controller should be
able to specify address-cells and size-cells properties and use
an addressed fan child node.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20251001144441.310950-6-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The binding for the max31785 is the same as the max31790, so just add
some compatible strings for the max31785 chip.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20251001144441.310950-5-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for the Murata NCP18WM474 NTC.
Compensation table has been constructed by linear interpolation between
well defined points[1] on the resistance vs. temperature graph in the
datasheet[2]. The readouts of the graph has been done to the best of my
abilities, but the compensation table will be subject to inaccuracies
nonetheless.
[1] -40, -25, 0, 25, 50, 75, 100, 125 degrees
[2] https://www.murata.com/en-eu/api/pdfdownloadapi?cate=&partno=NCP18WM474E03RB
Signed-off-by: Emil Dahl Juhl <juhl.emildahl@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20251001-ntc-thermistor-ncp18wm474-v1-1-2c64b9b509ff@pengutronix.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for MAX17616/MAX17616A current-limiter with
overvoltage/surge, undervoltage, reverse polarity, loss of ground
protection with PMBus interface. The PMBus interface allows monitoring
of input/output voltages, output current and temperature.
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Link: https://lore.kernel.org/r/20250930-upstream-max17616-v1-2-1525a85f126c@analog.com
[groeck: Fixed htmldocs 'WARNING: Title underline too short'
as reported by Kriish Sharma <kriish.sharma2006@gmail.com>]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Merge series from Benoît Monin <benoit.monin@bootlin.com>:
The DesignWare SPI controller can act as a host or a target; the
choice between the two is set in hardware and cannot be changed by
software. When configured in target mode, the controller has a much
reduced set of capabilities. It only has a single chip-select input and
can only run standard SPI mode (no dual, quad, or octal mode). Despite
this, the overall logic of doing an SPI transfer and the register layout
is identical between both modes, so implementing the target mode reuses
much of the existing code.
The first part of this two-patch series renames the spi_controller to
ctlr instead of host and also changes the suffix of the related functions
to controller. This is done to avoid confusion when referring to the
controller in target mode.
The second patch implements the target mode support by allocating an
SPI controller of the correct type based on the spi-slave property. The
controller is then configured differently depending on the mode. For
an SPI transfer, the same transfer_one() callback is used, with the
difference being in dw_spi_update_config() where only the CTRLR0
register is set. The other registers are not relevant in target mode
and are read-only.
I am posting this as an RFC because I could only perform partial testing
on my setup. I am using an SoC with two DesignWare SPI memory-mapped
controllers identified as Synopsys DWC APB SSI v4.03, one in host mode and
the other in target mode. On the evaluation board, a microcontroller acts
as an SPI relay between the two, but it has some limitations. The number
of bits per word is fixed, as are the clock phase and polarity. It also
only copies data from the host to the target. With this limited setup,
I did test that data can be successfully transferred from the host
to the target using spidev_test. I also checked that polling works by
temporarily disabling the IRQ, but I cannot test DMA. Therefore, more
testing on different devices would be welcome.
Merge series from Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>:
This patch series introduces several improvements to the
ASPEED SPI driver, targeting better stability, compatibility
and, flexibility across multiple ASPEED platforms.
Key changes include:
* Clock selection strategy update
Improves fallback logic when timing calibration is skipped or
fails, ensuring reliable boot behavior.
* Timing calibration enhancement for AST2600
Replaces the previous "first-pass" strategy with a more robust
algorithm that selects the optimal timing point.
* Default address decoding assignment
Ensures each chip select (CS) has a valid decoding range during
probe, avoiding detection failures due to missing or incorrect
bootloader setup.
* Centralized address decoding management
Refactors the decoding logic to centrally assign address windows,
preventing improper trimming and improving layout flexibility.
* Per-platform decoding adjustment
Introduces platform-specific `adjust_window` callbacks to handle
platform specific hardware constraints for address decoding range.
* Selective memory mapping
Optimizes memory usage by mapping only the required address window
per CS to avoid exhaustion.
Merge series from From git@z Thu Jan 1 00:00:00 1970
Axel Haslam <ahaslam@baylibre.com>:
Add an offset parameter that can be passed in the periodic trigger.
This is useful for example when ADC drivers implement a separate periodic
signal to trigger conversion and need offload to read the result with
some delay. While at it, add some documentation to offload periodic trigger
parameters.
Forward critical supply events downstream so consumers can react in
time. An under-voltage event on an upstream rail may otherwise never
reach end devices (e.g. eMMC).
Register a notifier on a regulator's supply when the supply is resolved,
and forward only REGULATOR_EVENT_UNDER_VOLTAGE to the consumer's notifier
chain. Event handling is deferred to process context via a workqueue; the
consumer rdev is lifetime-pinned and the rdev lock is held while calling
the notifier chain. The notifier is unregistered on regulator teardown.
No DT/UAPI changes. Behavior applies to all regulators with a supply.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://patch.msgid.link/20251001105650.2391477-1-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The tablet is similar to the 22R Pro, but with a few annoying
differences. Its descriptors are bigger because of the tablet's split
coordinate system, I guess it's just that large. Thankfully, this is
easy enough to support as all we have to do is shift bytes around.
To help code re-use, I changed the signature of
uclogic_params_init_ugee_xppen_pro to accept a pen descriptor so we
didn't create yet-another initialization function.
I have been testing this locally for a month or so and it works great,
and also corroborated this with a few other testers. Since this touches
my 22R Pro code, I have tested and checked that it didn't regress that
device.
Signed-off-by: Joshua Goins <josh@redstrate.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Currently, hidpp_send_message_sync() retries sending the message when the
device returns a busy error code, specifically HIDPP20_ERROR_BUSY, which
has a different meaning under RAP. This ends up being a problem because
this function is used for both FAP and RAP messages.
This issue is not noticeable on older receivers with unreachable devices
since they return HIDPP_ERROR_RESOURCE_ERROR (0x09), which is not equal to
HIDPP20_ERROR_BUSY (0x08).
However, newer receivers return HIDPP_ERROR_UNKNOWN_DEVICE (0x08) which
happens to equal to HIDPP20_ERROR_BUSY, causing unnecessary retries when
the device is not actually busy.
This is resolved by checking if the error response is FAP or RAP and
picking the respective ERROR_BUSY code.
Fixes: 60165ab774 ("HID: logitech-hidpp: rework one more time the retries attempts")
Signed-off-by: Mavroudis Chatzilazaridis <mavchatz@protonmail.com>
Tested-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
When logitech-hidpp tries to communicate with an unreachable device paired
to a 046d:c547 lightspeed receiver, the following message is printed to the
console:
hidpp_root_get_protocol_version: received protocol error 0x08
This occurs because this receiver returns 0x08 (HIDPP_ERROR_UNKNOWN_DEVICE)
when a device is unreachable, compared to 0x09 (HIDPP_ERROR_RESOURCE_ERROR)
that the older receivers return.
This patch silences this harmless error by treating
HIDPP_ERROR_UNKNOWN_DEVICE the same as HIDPP_ERROR_RESOURCE_ERROR
in hidpp_root_get_protocol_version().
There are other checks for HIDPP_ERROR_RESOURCE_ERROR found in
battery-related functions, however this receiver does not trigger them when
the device is disconnected.
Signed-off-by: Mavroudis Chatzilazaridis <mavchatz@protonmail.com>
Tested-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
This lightspeed receiver uses 13 byte mouse reports without an ID.
There are 5 additional vendor defined bytes appended to the report.
The workaround for such cases has been adjusted to handle these larger
reports.
The keyboard reports have a distinct layout with differing minimums and
maximums. Additionally, the LED reports now require a report ID of 1.
New keyboard and mouse descriptors have been added to reflect these
changes.
The devices attached to this receiver now report the status of their
battery in wireless mode, libratbag communicates with them and they can
be configured with Piper.
Fixes: 9d1bd93462 ("HID: logitech-dj: Add support for a new lightspeed receiver iteration")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218172
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218094
Co-developed-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Mavroudis Chatzilazaridis <mavchatz@protonmail.com>
Tested-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Add hw_brightness_changed support for the G510 keyboard, so that e.g.
GNOME will show an OSD notification when toggling the backlight on/off
with the button the keyboard.
Note that it is not possible to turn the backlight back on by writing
/sys/class/leds/.../brightness it can only be turned on by pressing
the button on the keyboard. To reflect this /sys/class/leds/.../brightness
will always report the last brightness value independent of the on/off
toggle built into the keyboard.
Signed-off-by: Hans de Goede <hansg@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Add support for Orion2 throttle configurations with more than 32 buttons
on the grip handle (this means the device reports more than 80 buttons).
Map additional button codes to KEY_MACRO1 .. KEY_MACRO28.
Make the module simpler, removing report descriptor fixup.
[jkosina@suse.com: fix changelog]
Signed-off-by: Ivan Gorinov <linux-kernel@altimeter.info>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The Logitech G13 is a gaming keypad with general-purpose macro keys,
four LED-backlit macro preset keys, five "menu" keys, backlight toggle
key, an analog thumbstick, RGB LED backlight, and a monochrome LCD
display.
Support input event generation for all keys and the thumbstick, and
expose all LEDs.
Signed-off-by: Leo L. Schwab <ewhac@ewhac.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Tested-by: Kate Hsuan <hpa@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Remove extraneous dropping of the lock just to call 'request_irq'
and locking again afterwards. Increment reference count
before calling 'request_irq'. Rollback reference count if
'request_irq' fails.
Suggested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Alex Tran <alex.t.tran@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
A commit 3a93d082ba ("ALSA: firewire-motu: add support for MOTU Audio
Express") describes a quirk of MOTU Audio Express. The device returns
acknowledge packet with 0x10 as the pending state of any types of
asynchronous request transaction. It is completely out of specification.
This commit implements handling for that device-specific quirk. The quirk
is detected after reading the root directory of configuration ROM. When
processing the acknowledge code in 1394 OHCI AT context event handler,
firewire-ohci module seeks the device instance of destination node by
traversing device hierarchy. If the device has the quirk, the acknowledge
code is replaced with the standard code.
The 1394 OHCI AT context events occur for outgoing asynchronous request
packets. The device traversal is safe since no new request initiators
exist after the fw_card_instance has been invalidated.
Link: https://lore.kernel.org/r/20251013140311.97159-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Every time the bus manager runs, the cached configuration ROM content of
the IRM device is investigated to detect device-specific quirks. This
detection can be performed in advance when reading the configuration ROM.
This commit adds device quirk flags to the fw_device structure, and
initializes them after reading the bus information block of the
configuration ROM. The quirk flags are immutable once the configuration
ROM has been read. Although they are likely accessed concurrently only by
the bus manager, this commit ensures safe access by preventing torn writes
and reads using the WRITE_ONCE()/READ_ONCE() macros.
Link: https://lore.kernel.org/r/20251013140311.97159-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
IPQ5332 contains the QPIC-SPI-NAND flash controller which is the same as
the one found in IPQ9574. So let's document the IPQ5332 compatible and
use IPQ9574 as the fallback.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
Link: https://patch.msgid.link/20251008090413.458791-3-quic_mdalam@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
IPQ5424 contains the QPIC-SPI-NAND flash controller which is the same as
the one found in IPQ9574. So let's document the IPQ5424 compatible and
use IPQ9574 as the fallback.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
Link: https://patch.msgid.link/20251008090413.458791-2-quic_mdalam@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add an offset parameter that can be passed in the periodic trigger.
This is useful for example when ADC drivers implement a separate periodic
signal to trigger conversion and need offload to read the result with
some delay. While at it, add some documentation to offload periodic trigger
parameters.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://patch.msgid.link/cd315e95c0bd8523f00e91c400abcd6a418e5924.1759760519.git.marcelo.schmitt@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Previously, the driver mapped the entire SPI address decoding region during
probe. On systems with small flash or limited memory, this could lead to
excessive memory usage or allocation failures.
This patch changes the strategy to initially map a small address window
for SPI flash device probing. After determining each chip select's flash
size, the driver unmaps the temporary region and remaps only the required
address window accordingly.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Link: https://patch.msgid.link/20251001112605.1130723-7-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Different ASPEED SoCs have specific limitations on SPI address decoding,
such as total range size, minimum window size per CS, and alignment
requirements. The original adjustment logic only handles simple cases
and could fail in more complex setups found in advanced board designs,
e.g., small flash on CS0 and large flash on CS1, or when the total physical
flash size exceeds the decoding range supported by the SPI controller.
This patch introduces a per-platform adjust_window callback to handle
these constraints properly. Each platform defines its own logic to
adjust decoding ranges, trim excess size, and ensure alignment.
If trimming is required, the affected CS will fall back to user mode
access to ensure the entire flash remains accessible from the MTD layer.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Link: https://patch.msgid.link/20251001112605.1130723-6-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The original approach to handling address decoding overlaps was to trim
the next region directly. If the next CS's decoding range was fully
overlapped by the current one, it would be forcibly closed by trimming
its size to zero. This could lead expected behavior, especially on
the platform with multiple flashes layout.
To solve improper trimming problem, this patch collects the required
address decoding size at each stage, then, (re-)arragne address decoding
region to each CS centrally with knowing the total AHB decoding size.
If a segment register cannot be updated (e.g. due to bootloader write
protection), the original value is kept to avoid breaking access and
an error is reported if the total decoding size of all CS exceeds
the total AHB decoding size.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Link: https://patch.msgid.link/20251001112605.1130723-5-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On some platforms, we cannot assume that the whole address decoding range
value is ready for each CS. Especially for chip selects other than CS0,
the address decoding range may not be properly configured before the kernel
stage, or the existing configuration may be unsuitable. This can lead to
SPI flash detection failures during driver probe.
To ensure reliable initialization, this patch forcibly assigns a default
address decoding range to each chip select based on a platform-specific
minimum window size. Unused chip selects are explicitly disabled to avoid
conflicts.
This change improves robustness across platforms with varying bootloader
behavior and ensures consistent SPI flash initialization.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Link: https://patch.msgid.link/20251001112605.1130723-4-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Starting with the AST2600 platform, most platfom manufacturers have
adopted more complex board designs and signal routing, making SPI
timing calibration increasingly sensitive and critical. Previously,
the driver selected the first "PASS" timing point during calibration,
which may not yield the most stable result.
This patch introduces a more robust calibration method:
- It evaluates all combinations of HCLK sample point delay and DI input
delay. The results are stored in a 2D buffer for further comparison.
- Because the timing delay behavior is non-linear across HCLK sample
points, the optimal timing point is selected as the center of the
longest consecutive "PASS" interval within a single HCLK sample
point row.
This approach ensures better stability and precision in SPI read timing,
especially under complex signal integrity conditions.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Link: https://patch.msgid.link/20251001112605.1130723-3-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch updates the SPI clock selection logic for cases where
timing calibration is not performed or the results are failed.
Timing calibration process is skipped in the two scenarios below.
- Low-entropy data in the calibration region:
The driver skips timing calibration if the data read from the
SPI flash contains mostly 0x00 or 0xFF. Originally, the driver
used a low-frequency clock to read this region as golden data.
However, due to variations in host characteristics and image
layout, we cannot assume sufficient entropy in this region to
ensure reliable calibration.
- Low-speed configurations (< 40MHz):
The ASPEED SPI controller does not support timing calibration when
the max_speed_hz of the SPI device is below 40MHz.
In both cases, the SPI clock frequency specified in the device tree
should be used directly. When timing calibration is skipped, it is
the board vendor's responsibility to ensure that the SPI flash
SI (Signal Integrity) is sufficient for reliable operation at the
configured frequency.
When timing calibration processes is execued and all potential clock
frequencies are performed, but are all failed, the lower clock frequency
should be adopted to ensure the overall system can boot up successfully.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Link: https://patch.msgid.link/20251001112605.1130723-2-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Implement target mode for the DesignWare controller with the following
changes:
Allocate an SPI controller of the correct type based on the spi-slave
property in dw_spi_add_controller() and set the controller properties
depending on its type. Since they are only relevant when acting as a host
controller, settings related to chip-select control and the set_cs()
callback are only set in host mode, as are the loopback support, the
memory operations and the maximum frequency. The target_abort() callback
is set only when configured in target mode.
The number of chip-select is set to 1 in dw_spi_hw_init() since the
controller only has one CS input in target mode.
In dw_spi_update_config(), return after setting the CTRLR0 register as
the other registers are only relevant in host mode and are read-only
in target mode. This function is called as part of the transfer_one()
callback, which is identical in both the host and target mode.
Move the code implementing the handle_err() callback to a new function
named dw_spi_abort(), and use it to implement both the handle_err()
and the target_abort() callbacks.
Finally, drop the error path on the spi-slave property in
dw_spi_mmio_probe(), as it is now a valid configuration.
Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
Link: https://patch.msgid.link/20251002-spi-dw-target-v1-2-993e91c1a712@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the designware SPI controller can act as both a target and a host,
rename spi_controller member of the dw_spi struct to ctlr instead of host.
Similarly, rename the functions handling the controller, using controller
instead of host as the suffix.
No functional changes intended.
Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
Link: https://patch.msgid.link/20251002-spi-dw-target-v1-1-993e91c1a712@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert the existing text-based DT bindings for Dialog Semiconductor DA9211
Voltage Regulators family to a DT schema. Examples are simplified, as these
are all equal.
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251001183648.83379-1-ariel.dalessandro@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We converted gpiod_set_value() and its variants to return an integer to
indicate failures. Check the return value where it's ignored currently
so that user-space agents controlling the virtual user module can get
notified about errors.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The arguments passed to dev_$level() macros are duplicated across the
gpiochip_$level() macros so put them under an intermediate wrapper.
While at it: wrap it in a do-while guard.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
A lot of code in gpiod_$level() macros is duplicated across all
definitions. Create an intermediate macro which allows us to reuse the
low-level code.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The chip_$level() macros take struct gpio_chip as argument so make it
follow the convention of using the 'gpiochip_' prefix.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
We don't need to add additional logs when returning -ENOMEM so remove
unnecessary error messages.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The cros-usbpd-notify-acpi probe currently does not exit when it fails
to get a pointer to the ChromeOS EC device. It is expected behavior on
older devices, where GOOG0004 is not a parent of GOOG0003.
Update the cros-usbpd-notify-acpi probe to check for a GOOG0004 parent
fwnode. If the device has correct device hierarchy and fails to get an
EC device pointer, defer the probe function.
Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20251007004043.4109957-1-jthies@google.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Add device tree documentation for MAX17616/MAX17616A current-limiter
with overvoltage/surge, undervoltage, reverse polarity, loss of ground
protection with PMBus interface.
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20250930-upstream-max17616-v1-1-1525a85f126c@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for MPS VR mp2925 and mp2929 controller. This driver exposes
telemetry and limit value readings and writtings.
Signed-off-by: Wensheng Wang <wenswang@yeah.net>
Link: https://lore.kernel.org/r/20250928092845.1394718-2-wenswang@yeah.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for MPS mp2925 and mp2929 controller.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Wensheng Wang <wenswang@yeah.net>
Link: https://lore.kernel.org/r/20250928092845.1394718-1-wenswang@yeah.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-12 14:14:22 -07:00
1230 changed files with 59069 additions and 15049 deletions
Linus Torvalds
Thomas Hellström
Bjorn Helgaas
Rob Herring (Arm)
Bartosz Golaszewski
Hans Zhang
Manikandan K Pillai
Vincent Guittot
Jiri Kosina
Gabriel Marcano
Dave Stevenson
Michael S. Tsirkin
Miquel Raynal
Thorsten Blum
Ivan Stepchenko
Randy Dunlap
Mikhail Zhilkin
Colin Ian King
Andy Shevchenko
David Matlack
Alex Williamson
Ankit Agrawal
Alex Mastro
Alex Williamson
Gui-Dong Han
Xi Ruoyao
Tianchu Chen
Haotian Zhang
Joerg Roedel
Jason Gunthorpe
Geert Uytterhoeven
Mark Brown
sparkhuang
Johan Hovold
Stefan Metzmacher
Mikhail Kshevetskiy
Biju Das
Leon Romanovsky
Nathan Chancellor
Marco Crivellari
Alok Tiwari
Mike Christie
Miaoqian Lin
Kriish Sharma
Guenter Roeck
Krzysztof Kozlowski
Lad Prabhakar
Krzysztof Kozlowski
Nicolin Chen
Juergen Gross
Benedek Kupper
Terry Junge
Hans de Goede
Nathan Rossi
Shawn Lin
Li RongQing
Jijun Wang
Jacob Moroni
Anil Samal
Krzysztof Czurylo
Tatyana Nikolova
Claudiu Beznea
Pratyush Yadav
Stephan Gerhold
Jinhui Guo
Marc Zyngier
Jean-Philippe Brucker
André Draszik
Jisheng Zhang
Ulf Hansson
Junjie Cao
Luca Ceresoli
Sarthak Garg
Sebastian Reichel
小太
Ilpo Järvinen
Lukas Wunner
Krishna Chaitanya Chundru
David Laight
Ryan Huang
Konrad Dybcio
Dan Carpenter
Cosmin Tanislav
Maher Sanalla
Yishai Hadas
Selvin Xavier
Junxian Huang
Siva Reddy Kallam
Billy Tsai
René Rebe
Heiko Stuebner
Mauro Carvalho Chehab
Jason Tian
Ping Cheng
Vivek Kasireddy
Riccardo Mereu
Marek Vasut
Andreas Kemnade
Charles Keepax
Benjamin Tissoires
Alejandro Enrique
Sjoerd Simons
Vikas Gupta
Kalesh AP
Fenglin Wu
Yuntao Wang
Konrad Dybcio
Conor Dooley
Jose Javier Rodriguez Barbarin
Frank Li
LI Qingwu
Lu Baolu
Aashish Sharma
Vineeth Pillai (Google)
Pierre-Henry Moussay
Brian Masney
Stanimir Varbanov
Nicolas Frattaroli
Finley Xiao
AngeloGioacchino Del Regno
Jishnu Prakash
Peng Fan
Xu Yang
Chen Ni
Raag Jadav
Levente Révész
Uwe Kleine-König
James Calligeros
Dave Jiang
Alison Schofield
Longbin Li
Alejandro Lucero
Thomas Zimmermann
Martijn de Gouw
Lukas Bulwahn
Carlos Song
Bagas Sanjaya
Krzysztof Kozlowski
Martin Blumenstingl
Binbin Zhou
Jakub Czapiga
Haibo Chen
Christian Bruel
Igor Reznichenko
Christophe JAILLET
David Heidelberg
Ariel D'Alessandro
Louis-Alexis Eyraud
Niravkumar L Rabara
Wolfram Sang
Erick Setubal Bacurau
Marek Vasut
Alex Elder
Daniel Golle
Christian Marangi
Abdun Nihaal
Kartik Rajput
Chin-Ting Kuo
Jonas Gorski
Robert Richter
Prajna Rajendra Kumar
Uwe Kleine-König
Benjamin Larsson
Mathieu Dubois-Briand
Diogo Ivo
Marius Zachmann
Bruno Thomsen
Takashi Sakamoto
Jun Guo
Anand Moon
Siddharth Vadapalli
Jim Quinlan
Mostafa Saleh
Samuel Kayode
Dheeraj Kumar Srivastava
Luca Weiss
Christian Hitz
Michal Wilczynski
Miguel Ojeda
Mika Westerberg
Jeff Lin
Tomer Maimon
Tuo Li
Breno Leitao
Qiang Ma
Charan Pedumuru
Huan He
Takahiro Kuwano
Ma Ke
Manivannan Sadhasivam
Tzung-Bi Shih
Patrisious Haddad
Leon Romanovsky
Gabor Juhos
Francesco Pompo
Raghavendra Rao Ananta
Duje Mihanović
Thomas Weißschuh
Troy Mitchell
Matti Vaittinen
Shree Ramamoorthy
Matthias Schiffer
Dr. David Alan Gilbert
Dzmitry Sankouski
Atharva Tiwari
Andreas Kemnade
Lee Jones
Clark Wang
Jay Bhat
Longfang Liu
Chu Guangqing
Alejandro Jimenez
Vishwaroop A
Songtang Liu
Li Ming
Gregory Price
Abel Vesa
Jingyi Wang
Joy Zou
ChiYuan Huang
Aurelien Jarno
Ahelenia Ziemiańska
Michal Kubecek
Val Packett
Ivan Abramov
Murad Masimov
Akhilesh Patil
Eugene Shalygin
Ankan Biswas
Willy Huang
Brady Norander
Zhongqiu Han
Sakari Ailus
Sander Vanheule
Dan Williams
Alexander Usyskin
Richard Genoud
Aryan Srivastava
Zhu Yanjun
Oleksij Rempel
Jean Delvare
Zhengnan Chen
Pedro Demarchi Gomes
Håkon Bugge
Sean Anderson
Bhanu Seshu Kumar Valluri
Thomas Richard
Avri Altman
Can Peng
Vaibhav Gupta
Samuel Kayode
Mary Strodl
Markus Elfring
Kamal Dasu
Manish Pandey
Oliver Neukum
Sicelo A. Mhlongo
Jean-François Lessard
Harrison Carter
Michael Roth
Colin Ian King
Qiang Yu
Yao Zi
Zhang Lixu
Nuno Sá
Christophe Leroy
Prathamesh Shete
Francesco Lavra
Ioana Ciornei
Kamal Wadhwa
Cosmo Chou
Kim Seer Paller
Ivan Mikhaylov
Maximilian Luz
Paul Heneghan
Alexis Czezar Torreno
Eddie James
Emil Dahl Juhl
Sascha Hauer
Joshua Goins
Mavroudis Chatzilazaridis
Hans de Goede
Ivan Gorinov
Leo L. Schwab
Alex Tran
Md Sadre Alam
Axel Haslam
Benoît Monin
Jameson Thies
Wensheng Wang