aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-11-01virtio: add definition of VIRTIO_F_NOTIF_CONFIG_DATA feature bitXuan Zhuo1-0/+5
This patch adds the definition of VIRTIO_F_NOTIF_CONFIG_DATA feature bit in the relevant header file. This feature indicates that the driver uses the data provided by the device as a virtqueue identifier in available buffer notifications. It comes from here: https://github.com/oasis-tcs/virtio-spec/issues/89 Signed-off-by: Xuan Zhuo <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]>
2023-11-01vduse: make vduse_class constantGreg Kroah-Hartman1-19/+21
Now that the driver core allows for struct class to be in read-only memory, we should make all 'class' structures declared at build time placing them into read-only memory, instead of having to be dynamically allocated at runtime. Cc: "Michael S. Tsirkin" <[email protected]> Cc: Jason Wang <[email protected]> Cc: Xuan Zhuo <[email protected]> Cc: Xie Yongji <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Message-Id: <2023100643-tricolor-citizen-6c2d@gregkh> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Xie Yongji <[email protected]> Acked-by: Jason Wang <[email protected]>
2023-11-01vhost-scsi: Spelling s/preceeding/preceding/gGeert Uytterhoeven1-1/+1
Fix a misspelling of "preceding". Signed-off-by: Geert Uytterhoeven <[email protected]> Message-Id: <b57b882675809f1f9dacbf42cf6b920b2bea9cba.1695903476.git.geert+renesas@glider.be> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]>
2023-11-01virtio: kdoc for struct virtio_pci_modern_deviceShannon Nelson1-12/+22
Finally following up to Simon's suggestion for some kdoc attention on struct virtio_pci_modern_device. Link: https://lore.kernel.org/netdev/ZE%[email protected]/ Cc: Simon Horman <[email protected]> Signed-off-by: Shannon Nelson <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]>
2023-11-01vdpa: Update sysfs ABI documentationShawn.Shao1-2/+2
Fix the wrong drivers_autoprobe path name in the document Signed-off-by: Shawn.Shao <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]>
2023-11-01MAINTAINERS: Add myself as mlx5_vdpa driverDragos Tatulea1-0/+6
As Eli Cohen moved to other work, I'll be the contact point for mlx5_vdpa. Acked-by: Jason Wang <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2023-11-01virtio-balloon: correct the comment of virtballoon_migratepage()Xueshi Hu1-1/+1
After commit 68f2736a8583 ("mm: Convert all PageMovable users to movable_operations"), the execution path has been changed to move_to_new_folio movable_operations->migrate_page balloon_page_migrate balloon_page_migrate->balloon_page_migrate balloon_page_migrate Correct the outdated comment. Signed-off-by: Xueshi Hu <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Xuan Zhuo <[email protected]>
2023-11-01mlx5_vdpa: offer VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OKEugenio Pérez1-0/+7
Offer this backend feature as mlx5 is compatible with it. It allows it to do live migration with CVQ, dynamically switching between passthrough and shadow virtqueue. Signed-off-by: Eugenio Pérez <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2023-11-01vdpa/mlx5: Update cvq iotlb mapping on ASID changeDragos Tatulea3-1/+36
For the following sequence: - cvq group is in ASID 0 - .set_map(1, cvq_iotlb) - .set_group_asid(cvq_group, 1) ... the cvq mapping from ASID 0 will be used. This is not always correct behaviour. This patch adds support for the above mentioned flow by saving the iotlb on each .set_map and updating the cvq iotlb with it on a cvq group change. Acked-by: Jason Wang <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Make iotlb helper functions more genericDragos Tatulea1-8/+11
They will be used in a follow-up patch. For dup_iotlb, avoid the src == dst case. This is an error. Acked-by: Jason Wang <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Enable hw support for vq descriptor mappingDragos Tatulea2-2/+29
Vq descriptor mappings are supported in hardware by filling in an additional mkey which contains the descriptor mappings to the hw vq. A previous patch in this series added support for hw mkey (mr) creation for ASID 1. This patch fills in both the vq data and vq descriptor mkeys based on group ASID mapping. The feature is signaled to the vdpa core through the presence of the .get_vq_desc_group op. Acked-by: Jason Wang <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Introduce mr for vq descriptorDragos Tatulea3-14/+25
Introduce the vq descriptor group and mr per ASID. Until now .set_map on ASID 1 was only updating the cvq iotlb. From now on it also creates a mkey for it. The current patch doesn't use it but follow-up patches will add hardware support for mapping the vq descriptors. Acked-by: Jason Wang <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Improve mr update flowDragos Tatulea3-72/+82
The current flow for updating an mr works directly on mvdev->mr which makes it cumbersome to handle multiple new mr structs. This patch makes the flow more straightforward by having mlx5_vdpa_create_mr return a new mr which will update the old mr (if any). The old mr will be deleted and unlinked from mvdev. For the case when the iotlb is empty (not NULL), the old mr will be cleared. This change paves the way for adding mrs for different ASIDs. The initialized bool is no longer needed as mr is now a pointer in the mlx5_vdpa_dev struct which will be NULL when not initialized. Acked-by: Eugenio Pérez <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Move mr mutex out of mr structDragos Tatulea3-11/+12
The mutex is named like it is supposed to protect only the mkey but in reality it is a global lock for all mr resources. Shift the mutex to it's rightful location (struct mlx5_vdpa_dev) and give it a more appropriate name. Signed-off-by: Dragos Tatulea <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Acked-by: Jason Wang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Allow creation/deletion of any given mr structDragos Tatulea3-35/+36
This patch adapts the mr creation/deletion code to be able to work with any given mr struct pointer. All the APIs are adapted to take an extra parameter for the mr. mlx5_vdpa_create/delete_mr doesn't need a ASID parameter anymore. The check is done in the caller instead (mlx5_set_map). This change is needed for a followup patch which will introduce an additional mr for the vq descriptor data. Signed-off-by: Dragos Tatulea <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Acked-by: Jason Wang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Rename mr destroy functionsDragos Tatulea3-11/+11
Make mlx5_destroy_mr symmetric to mlx5_create_mr. Acked-by: Jason Wang <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Collapse "dvq" mr add/delete functionsDragos Tatulea1-11/+5
Now that the cvq code is out of mlx5_vdpa_create/destroy_mr, the "dvq" functions can be folded into their callers. Having "dvq" in the naming will no longer be accurate in the downstream patches. Acked-by: Jason Wang <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Take cvq iotlb lock during refreshDragos Tatulea1-1/+9
The reslock is taken while refresh is called but iommu_lock is more specific to this resource. So take the iommu_lock during cvq iotlb refresh. Based on Eugenio's patch [0]. [0] https://lore.kernel.org/lkml/[email protected]/ Acked-by: Jason Wang <[email protected]> Suggested-by: Eugenio Pérez <[email protected]> Reviewed-by: Eugenio Pérez <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Decouple cvq iotlb handling from hw mapping codeDragos Tatulea3-39/+28
The handling of the cvq iotlb is currently coupled with the creation and destruction of the hardware mkeys (mr). This patch moves cvq iotlb handling into its own function and shifts it to a scope that is not related to mr handling. As cvq handling is just a prune_iotlb + dup_iotlb cycle, put it all in the same "update" function. Finally, the destruction path is handled by directly pruning the iotlb. After this move is done the ASID mr code can be collapsed into a single function. Acked-by: Jason Wang <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa/mlx5: Create helper function for dma mappingsDragos Tatulea3-2/+8
Necessary for upcoming cvq separation from mr allocation. Acked-by: Jason Wang <[email protected]> Signed-off-by: Dragos Tatulea <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vhost-vdpa: uAPI to get dedicated descriptor group idSi-Wei Liu2-0/+18
With _F_DESC_ASID backend feature, the device can now support the VHOST_VDPA_GET_VRING_DESC_GROUP ioctl, and it may expose the descriptor table (including avail and used ring) in a different group than the buffers it contains. This new uAPI will fetch the group ID of the descriptor table. Signed-off-by: Si-Wei Liu <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Acked-by: Jason Wang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vhost-vdpa: introduce descriptor group backend featureSi-Wei Liu2-0/+22
Userspace knows if the device has dedicated descriptor group or not by checking this feature bit. It's only exposed if the vdpa driver backend implements the .get_vq_desc_group() operation callback. Userspace trying to negotiate this feature when it or the dependent _F_IOTLB_ASID feature hasn't been exposed will result in an error. Signed-off-by: Si-Wei Liu <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Acked-by: Jason Wang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01vdpa: introduce dedicated descriptor group for virtqueueSi-Wei Liu1-0/+11
In some cases, the access to the virtqueue's descriptor area, device and driver areas (precluding indirect descriptor table in guest memory) may have to be confined to a different address space than where its buffers reside. Without loss of simplicity and generality with already established terminology, let's fold up these 3 areas and call them as a whole as descriptor table group, or descriptor group for short. Specifically, in case of split virtqueues, descriptor group consists of regions for Descriptor Table, Available Ring and Used Ring; for packed virtqueues layout, descriptor group contains Descriptor Ring, Driver and Device Event Suppression structures. The group ID for a dedicated descriptor group can be obtained through a new .get_vq_desc_group() op. If driver implements this op, it means that the descriptor, device and driver areas of the virtqueue may reside in a dedicated group than where its buffers reside, a.k.a the default virtqueue group through the .get_vq_group() op. In principle, the descriptor group may or may not have same group ID as the default group. Even if the descriptor group has a different ID, meaning the vq's descriptor group areas can optionally move to a separate address space than where guest memory resides, the descriptor group may still start from a default address space, same as where its buffers reside. To move the descriptor group to a different address space, .set_group_asid() has to be called to change the ASID binding for the group, which is no different than what needs to be done on any other virtqueue group. On the other hand, the .reset() semantics also applies on descriptor table group, meaning the device reset will clear all ASID bindings and move all virtqueue groups including descriptor group back to the default address space, i.e. in ASID 0. QEMU's shadow virtqueue is going to utilize dedicated descriptor group to speed up map and unmap operations, yielding tremendous downtime reduction by avoiding the full and slow remap cycle in SVQ switching. Signed-off-by: Si-Wei Liu <[email protected]> Acked-by: Eugenio Pérez <[email protected]> Acked-by: Jason Wang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu <[email protected]> Tested-by: Lei Yang <[email protected]>
2023-11-01Merge branch 'mlx5-vhost' of ↵Michael S. Tsirkin1-1/+7
https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git This merges a single commit that contains changes to mlx5_ifc.h It's required to support vq descriptor mappings in mlx5/vdpa Signed-off-by: Michael S. Tsirkin <[email protected]>
2023-11-01leds: lp5521: Add an error check in lp5521_post_init_deviceSu Hui1-0/+2
lp55xx_write() can return an error code, add a check for this. Signed-off-by: Su Hui <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: gpio: Update headersAndy Shevchenko1-1/+5
Include headers which we are direct users of, no need to have proxies. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: gpio: Remove unneeded assignmentAndy Shevchenko1-1/+1
The initial ret is not used anywhere, drop the unneeded assignment. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: gpio: Move temporary variable for struct device to gpio_led_probe()Andy Shevchenko1-11/+8
Use temporary variable for struct device in gpio_led_probe() in order to make code neater. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: gpio: Refactor code to use devm_gpiod_get_index_optional()Andy Shevchenko1-4/+4
Instead of checking for the specific error codes, replace devm_gpiod_get_index() with devm_gpiod_get_index_optional(). In this case we just return all errors to the caller and simply check for NULL in case if legacy GPIO is being used. As the result the code is easier to read and maintain. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: gpio: Utilise PTR_ERR_OR_ZERO()Andy Shevchenko1-10/+7
Avoid a boilerplate code by using PTR_ERR_OR_ZERO() in create_gpio_led(). Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: gpio: Keep driver firmware interface agnosticAndy Shevchenko1-3/+3
The of.h is used as a proxy to mod_devicetable, replace former by latter. The commit 2d6180147e92 ("leds: gpio: Configure per-LED pin control") added yet another unneeded OF APIs. Replace with direct use of fwnode. Altogether this makes driver agnostic to the firmware interface in use. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: core: Refactor led_update_brightness() to use standard patternAndy Shevchenko1-6/+6
The standard conditional pattern is to check for errors first and bail out if any. Refactor led_update_brightness() accordingly. While at it, drop unneeded assignment and return 0 unconditionally on success. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Denis Osterland-Heim <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: turris-omnia: Fix brightness setting and trigger activatingMarek Behún1-17/+20
I have improperly refactored commits 4d5ed2621c24 ("leds: turris-omnia: Make set_brightness() more efficient") and aaf38273cf76 ("leds: turris-omnia: Support HW controlled mode via private trigger") after Lee requested a change in API semantics of the new functions I introduced in commit 28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls"). Before the change, the function omnia_cmd_write_u8() returned 0 on success, and afterwards it returned a positive value (number of bytes written). The latter version was applied, but the following commits did not properly account for this change. This results in non-functional LED's .brightness_set_blocking() and trigger's .activate() methods. The main reasoning behind the semantics change was that read/write methods should return the number of read/written bytes on success. It was pointed to me [1] that this is not always true (for example the regmap API does not do so), and since the driver never uses this number of read/written bytes information, I decided to fix this issue by changing the functions to the original semantics (return 0 on success). [1] https://lore.kernel.org/linux-gpio/[email protected]/ Fixes: 28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls") Signed-off-by: Marek Behún <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: sc27xx: Move mutex_init() downChunyan Zhang1-3/+2
Move the mutex_init() to avoid redundant mutex_destroy() calls after that for each time the probe fails. Signed-off-by: Chunyan Zhang <[email protected]> Reviewed-by: Baolin Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: trigger: netdev: Move size check in set_device_nameChristian Marangi1-3/+3
GCC 13.2 complains about array subscript 17 is above array bounds of 'char[16]' with IFNAMSIZ set to 16. The warning is correct but this scenario is impossible. set_device_name is called by device_name_store (store sysfs entry) and netdev_trig_activate. device_name_store already check if size is >= of IFNAMSIZ and return -EINVAL. (making the warning scenario impossible) netdev_trig_activate works on already defined interface, where the name has already been checked and should already follow the condition of strlen() < IFNAMSIZ. Aside from the scenario being impossible, set_device_name can be improved to both mute the warning and make the function safer. To make it safer, move size check from device_name_store directly to set_device_name and prevent any out of bounds scenario. Cc: [email protected] Fixes: 28a6a2ef18ad ("leds: trigger: netdev: refactor code setting device name") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: Add ktd202x driverAndré Apitzsch3-0/+639
This commit adds support for Kinetic KTD2026/7 RGB/White LED driver. Signed-off-by: André Apitzsch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01dt-bindings: leds: Add Kinetic KTD2026/2027 LEDAndré Apitzsch1-0/+171
Document Kinetic KTD2026/2027 LED driver devicetree bindings. Signed-off-by: André Apitzsch <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: core: Add more colors from DT bindings to led_colorsOndrej Jirman1-0/+5
The colors are already part of DT bindings. Make sure the kernel is able to convert them to strings. Signed-off-by: Ondrej Jirman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01dt-bindings: leds: Last color ID is now 14 (LED_COLOR_ID_LIME)Ondrej Jirman1-1/+1
Increase the limit to match available values in dt-bindings/leds/common.h Fixes: 472d7b9e8141 ("dt-bindings: leds: Expand LED_COLOR_ID definitions") Signed-off-by: Ondrej Jirman <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: tca6507: Don't use fixed GPIO baseAndy Shevchenko1-7/+1
First of all, the fixed GPIO base is source of troubles and it doesn't scale. Second, there is no in-kernel user of this base, so drop it. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: lp3952: Convert to use maple tree register cacheMark Brown1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: lm392x: Convert to use maple tree register cacheMark Brown1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: aw200xx: Convert to use maple tree register cacheMark Brown1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: lm3601x: Convert to use maple tree register cacheMark Brown1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: triggers: gpio: Rewrite to use trigger-sourcesLinus Walleij2-101/+41
By providing a GPIO line as "trigger-sources" in the FWNODE (such as from the device tree) and combining with the GPIO trigger, we can support a GPIO LED trigger in a natural way from the hardware description instead of using the custom sysfs and deprecated global GPIO numberspace. Example: gpio: gpio@0 { compatible "my-gpio"; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; #trigger-source-cells = <2>; }; leds { compatible = "gpio-leds"; led-my-gpio { label = "device:blue:myled"; gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; default-state = "off"; linux,default-trigger = "gpio"; trigger-sources = <&gpio 1 GPIO_ACTIVE_HIGH>; }; }; Make this the norm, unmark the driver as broken. Delete the sysfs handling of GPIOs. Since GPIO descriptors inherently can describe inversion, the inversion handling can just be deleted. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01dt-bindings: leds: Mention GPIO triggersLinus Walleij1-0/+2
We reuse the trigger-sources phandle to just point to GPIOs we may want to use as LED triggers. Example: gpio: gpio@0 { compatible "my-gpio"; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; #trigger-source-cells = <2>; }; leds { compatible = "gpio-leds"; led-my-gpio { label = "device:blue:myled"; gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; default-state = "off"; linux,default-trigger = "gpio"; trigger-sources = <&gpio 1 GPIO_ACTIVE_HIGH>; }; }; Signed-off-by: Linus Walleij <[email protected]> Acked-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: pca955x: Cleanup OF/ID table terminatorsBiju Das1-20/+20
Some cleanups: * Remove the trailing comma in the terminator entry for the OF table making code robust against (theoretical) misrebases or other similar things where the new entry goes _after_ the termination without the compiler noticing. * Drop a space from terminator entry for ID table. While at it, move OF/ID table near to the user. Signed-off-by: Biju Das <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: pca955x: Convert enum->pointer for data in the match tablesBiju Das1-31/+18
Convert enum->pointer for data in the match tables, so that device_get_match_data() can do match against OF/ACPI/I2C tables, once i2c bus type match support added to it. Replace enum->struct *pca955x_chipdefs for data in the match table. Simplify the probe() by replacing device_get_match_data() and ID lookup for retrieving data by i2c_get_match_data(). While at it, add const definition to pca955x_chipdefs[]. Signed-off-by: Biju Das <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: lp3952: Replace deprecated strncpy with strscpyJustin Stitt1-1/+1
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We expect `dest` to be NUL-terminated due to its use with dev_err. lp3952_get_label()'s dest argument is priv->leds[i].name: | acpi_ret = lp3952_get_label(&priv->client->dev, led_name_hdl[i], | priv->leds[i].name); ... which is then assigned to: | priv->leds[i].cdev.name = priv->leds[i].name; ... which is used with a format string | dev_err(&priv->client->dev, | "couldn't register LED %s\n", | priv->leds[i].cdev.name); There is no indication that NUL-padding is required but if it is let's opt for strscpy_pad. Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/20230922-strncpy-drivers-leds-leds-lp3952-c-v1-1-4941d6f60ca4@google.com Signed-off-by: Lee Jones <[email protected]>
2023-11-01leds: trigger: ledtrig-cpu:: Fix 'output may be truncated' issue for 'cpu'Christophe JAILLET1-2/+2
In order to teach the compiler that 'trig->name' will never be truncated, we need to tell it that 'cpu' is not negative. When building with W=1, this fixes the following warnings: drivers/leds/trigger/ledtrig-cpu.c: In function ‘ledtrig_cpu_init’: drivers/leds/trigger/ledtrig-cpu.c:155:56: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 [-Werror=format-truncation=] 155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu); | ^~ drivers/leds/trigger/ledtrig-cpu.c:155:52: note: directive argument in the range [-2147483648, 7] 155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu); | ^~~~~~~ drivers/leds/trigger/ledtrig-cpu.c:155:17: note: ‘snprintf’ output between 5 and 15 bytes into a destination of size 8 155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 8f88731d052d ("led-triggers: create a trigger for CPU activity") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/3f4be7a99933cf8566e630da54f6ab913caac432.1695453322.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.