- 17 Oct, 2023 6 commits
-
-
Srinivas Pandruvada authored
With the increase in the CPU count, this count needs to be updated. Increase max CPU count to 512. Signed-off-by:Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
-
Srinivas Pandruvada authored
When core-power is getting enabled, if the feaure is not supported, display error. Signed-off-by: -
Srinivas Pandruvada authored
Don't call to set or get TRL for domains in which there are no CPUs. Signed-off-by: -
Srinivas Pandruvada authored
The command for turbo-mode enable and disable is swapped. Fix that. Previously turbo-mode enable was actually disabling and disable was enabling. Signed-off-by: -
Srinivas Pandruvada authored
TRL (turbo ratio limit) argument is passed in hex string. Clarify that in the help. Signed-off-by: -
Srinivas Pandruvada authored
If the command takes some integer arguments, make sure the command contains only digits. Same for Hex arguments. Otherwise return error. Signed-off-by:
-
- 21 Sep, 2023 11 commits
-
-
Andy Shevchenko authored
We can replace p = strchrnul(str, '$OLD'); *p = '\0'; with strreplace(str, '$OLD', '\0'); that does the compatible modification without a need of the temporary variable. Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230918135116.1248560-2-andriy.shevchenko@linux.intel.comReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Andy Shevchenko authored
Replace open coded functionalify of kstrdup_and_replace() with a call. Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20230917203805.1149595-8-u.kleine-koenig@pengutronix.deReviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Hans de Goede authored
gpio_crystalcove pin 10 is already in input mode and passing GPIOD_IN when requesting the GPIO changes its pull-up/-down settings causing the 830F/L to get misdetected as 1050F/L. Switch to using GPIOD_ASIS when requesting the GPIO to fix the misdetection. Fixes: 4014ae23 ("platform/x86: x86-android-tablets: Stop using gpiolib private APIs") Signed-off-by:
-
Mark Pearson authored
On Lenovo platforms there is a limitation in the number of times an attribute can be saved. This is an architectural limitation and it limits the number of attributes that can be modified to 48. A solution for this is instead of the attribute being saved after every modification allow a user to bulk set the attributes and then trigger a final save. This allows unlimited attributes. This patch introduces a save_settings attribute that can be configured to either single or bulk mode by the user. Single mode is the default but customers who want to avoid the 48 attribute limit can enable bulk mode. Displaying the save_settings attribute will display the enabled mode. When in bulk mode writing 'save' to the save_settings attribute will trigger a save. Once this has been done a reboot is required before more attributes can be modified. Signed-off-by:
Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20230919141530.4805-1-mpearson-lenovo@squebb.caReviewed-by:
-
- 13 Sep, 2023 1 commit
-
-
Shravan Kumar Ramani authored
Add new access mechanism and list of supported events to program and read the counters in BlueField-3. Performance counter blocks being added for BlueField-3 include: - Memory Sub-system (mss) which has counters for monitoring various DRAM and related skylib events - Last level Tile, which has 2 sets of counters (llt, llt_miss) for monitoring Tile and cache metrics Signed-off-by:
Shravan Kumar Ramani <shravankr@nvidia.com> Reviewed-by:
Vadim Pasternak <vadimp@nvidia.com> Reviewed-by:
David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/d5feee745f6bfd163e0c361e300d4b2ef1d72e00.1693917738.git.shravankr@nvidia.comSigned-off-by:
-
- 12 Sep, 2023 3 commits
-
-
Luke D. Jones authored
Add support for the WMI methods used to turn off and adjust the brightness of the secondary "screenpad" device found on some high-end ASUS laptops like the GX650P series and others. There are some small quirks with this device when considering only the raw WMI methods: 1. The Off method can only switch the device off 2. Changing the brightness turns the device back on 3. To turn the device back on the brightness must be > 1 4. When the device is off the brightness can't be changed (so it is stored by the driver if device is off). 5. Booting with a value of 0 brightness (retained by bios) means the bios will set a value of >0 <15 6. When the device is off it is "unplugged" asus_wmi sets the minimum brightness as 20 in general use, and 60 for booting with values <= min. The ACPI methods are used in a new backlight device named asus_screenpad. Signed-off-by:
Luke D. Jones <luke@ljones.dev> Link: https://lore.kernel.org/r/20230830032237.42987-2-luke@ljones.devReviewed-by:
-
Hans de Goede authored
-
Hans de Goede authored
Add a comment explaining why the special x86_android_tablet_get_gpiod() helper is necessary for some of the GPIOs used in the x86-android-tablets; and that for normal GPIO lookups this example should not be followed. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20230911210928.264908-1-hdegoede@redhat.com
-
- 11 Sep, 2023 15 commits
-
-
Hans de Goede authored
The "linux,power-supply-name" property is a left-over from an earlier attempt to allow properties to specify the power_supply class-device name. The patch to read this property never made it upstream (and is no longer necessary). Drop the unused property. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230909141816.58358-9-hdegoede@redhat.com
-
Hans de Goede authored
Use the new x86-android-tablets platform-device as gpio-keys parent to make it clear that this gpio-keys device was instantiated by the x86-android-tablets driver. Signed-off-by:
-
Hans de Goede authored
Refactor x86_android_tablet_get_gpiod() to no longer use gpiolib private functions like gpiochip_find(). As a bonus this allows specifying that the GPIO is active-low, like the /CE (charge enable) pin on the bq25892 charger on the Lenovo Yoga Tablet 3. Reported-by:
Bartosz Golaszewski <brgl@bgdev.pl> Closes: https://lore.kernel.org/platform-driver-x86/20230905185309.131295-12-brgl@bgdev.pl/Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
-
Hans de Goede authored
Create a platform_device from module_init() and change x86_android_tablet_init() / cleanup() into platform_device probe() and remove() functions. This is a preparation patch for refactoring x86_android_tablet_get_gpiod() to no longer use gpiolib private functions like gpiochip_find(). Signed-off-by:
-
Hans de Goede authored
x86_dev_info.invalid_aei_gpiochip is no longer used by any boards and the x86-android-tablets code should not use the gpiolib private acpi_gpiochip_free_interrupts() function. Reported-by:
-
Hans de Goede authored
Remove the invalid_aei_gpiochip setting from the x86_dev_info for the Peaq C1010. This is no longer necessary since there now is a quirk to ignore the "dolby" button GPIO in gpiolib_acpi_quirks[] in drivers/gpio/gpiolib-acpi.c . Signed-off-by:
-
Hans de Goede authored
On the Peaq C1010 2-in-1 INT33FC:00 pin 3 is connected to a "dolby" button. At the ACPI level an _AEI event-handler is connected which sets an ACPI variable to 1 on both edges. This variable can be polled + cleared to 0 using WMI. Since the variable is set on both edges the WMI interface is pretty useless even when polling. So instead of writing a custom WMI driver for this the x86-android-tablets code instantiates a gpio-keys platform device for the "dolby" button. Add an ignore_interrupt quirk for INT33FC:00 pin 3 on the Peaq C1010, so that it is not seen as busy when the gpio-keys driver requests it. Note this replaces a hack in x86-android-tablets where it would call acpi_gpiochip_free_interrupts() on the INT33FC:00 GPIO controller. acpi_gpiochip_free_interrupts() is considered private (internal) gpiolib API so x86-android-tablets should stop using it. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
-
Hans de Goede authored
In some cases where a broken AEI is present for a GPIO and the GPIO is listed in the ignore_interrupt list to avoid the broken event handler, the kernel may want to use the GPIO for another purpose. Before this change trying to use such a GPIO for another purpose would fail, because the ignore_interrupt list was only checked after the acpi_request_own_gpiod() call, causing the GPIO to already be claimed even though it is listed in the ignore_interrupt list. Fix this by moving the ignore_interrupt list to above the acpi_request_own_gpiod() call. Signed-off-by:
-
Luke D. Jones authored
Add quirk for ASUS ROG X16 (GV601V, 2023 versions) Flow 2-in-1 to enable tablet mode with lid flip (all screen rotations). Signed-off-by:
-
Geert Uytterhoeven authored
The only probing method supported by the Nvidia SN2201 platform driver is probing through an ACPI match table. Hence add a dependency on ACPI, to prevent asking the user about this driver when configuring a kernel without ACPI support. Fixes: 662f2482 ("platform/mellanox: Add support for new SN2201 system") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/ec5a4071691ab08d58771b7732a9988e89779268.1693828363.git.geert+renesas@glider.beSigned-off-by:
-
David Thompson authored
The latest version of the mlxbf_bootctl driver utilizes "sysfs_format_mac", and this API is only available if NET is defined in the kernel configuration. This patch changes the mlxbf_bootctl Kconfig to depend on NET. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309031058.JvwNDBKt-lkp@intel.com/Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Shravan Kumar Ramani authored
This fix involves 2 changes: - All event regs have a reset value of 0, which is not a valid event_number as per the event_list for most blocks and hence seen as an error. Add a "disable" event with event_number 0 for all blocks. - The enable bit for each counter need not be checked before reading the event info, and hence removed. Fixes: 1a218d31 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by:
-
Shravan Kumar Ramani authored
Replace sprintf with sysfs_emit where possible. Size check in mlxbf_pmc_event_list_show should account for "\0". Fixes: 1a218d31 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by:
-
Liming Sun authored
This commit drops over-sized network packets to avoid tmfifo queue stuck. Fixes: 1357dfd7 ("platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc") Signed-off-by:
Liming Sun <limings@nvidia.com> Reviewed-by:
-
Liming Sun authored
This commit fixes tmfifo console stuck issue when the virtual networking interface is in down state. In such case, the network Rx descriptors runs out and causes the Rx network packet staying in the head of the tmfifo thus blocking the console packets. The fix is to drop the Rx network packet when no more Rx descriptors. Function name mlxbf_tmfifo_release_pending_pkt() is also renamed to mlxbf_tmfifo_release_pkt() to be more approperiate. Fixes: 1357dfd7 ("platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc") Signed-off-by:
-
- 10 Sep, 2023 4 commits
-
-
Linus Torvalds authored
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm ci scripts from Dave Airlie: "This is a bunch of ci integration for the freedesktop gitlab instance where we currently do upstream userspace testing on diverse sets of GPU hardware. From my perspective I think it's an experiment worth going with and seeing how the benefits/noise playout keeping these files useful. Ideally I'd like to get this so we can do pre-merge testing on PRs eventually. Below is some info from danvet on why we've ended up making the decision and how we can roll it back if we decide it was a bad plan. Why in upstream? - like documentation, testcases, tools CI integration is one of these things where you can waste endless amounts of time if you accidentally have a version that doesn't match your source code - but also like the above, there's a balance, this is the initial cut of what we think makes sense to keep in sync vs out-of-tree, probably needs adjustment - gitlab supports out-of-repo gitlab integration and that's what's been used for the kernel in drm, but it results in per-driver fragmentation and lots of duplicated effort. the simple act of smashing an arbitrary winner into a topic branch already started surfacing patches on dri-devel and sparking good cross driver team discussions Why gitlab? - it's not any more shit than any of the other CI - drm userspace uses it extensively for everything in userspace, we have a lot of people and experience with this, including integration of hw testing labs - media userspace like gstreamer is also on gitlab.fd.o, and there's discussion to extend this to the media subsystem in some fashion Can this be shared? - there's definitely a pile of code that could move to scripts/ if other subsystem adopt ci integration in upstream kernel git. other bits are more drm/gpu specific like the igt-gpu-tests/tools integration - docker images can be run locally or in other CI runners Will we regret this? - it's all in one directory, intentionally, for easy deletion - probably 1-2 years in upstream to see whether this is worth it or a Big Mistake. that's roughly what it took to _really_ roll out solid CI in the bigger userspace projects we have on gitlab.fd.o like mesa3d" * tag 'topic/drm-ci-2023-08-31-1' of git://anongit.freedesktop.org/drm/drm: drm: ci: docs: fix build warning - add missing escape drm: Add initial ci/ subdirectory -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Ingo Molnar: "Fix preemption delays in the SGX code, remove unnecessarily UAPI-exported code, fix a ld.lld linker (in)compatibility quirk and make the x86 SMP init code a bit more conservative to fix kexec() lockups" * tag 'x86-urgent-2023-09-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sgx: Break up long non-preemptible delays in sgx_vepc_release() x86: Remove the arch_calc_vm_prot_bits() macro from the UAPI x86/build: Fix linker fill bytes quirk/incompatibility for ld.lld x86/smp: Don't send INIT to non-present and non-booted CPUs
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 perf event fix from Ingo Molnar: "Work around a firmware bug in the uncore PMU driver, affecting certain Intel systems" * tag 'perf-urgent-2023-09-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/uncore: Correct the number of CHAs on EMR
-
