- 07 Mar, 2023 40 commits
-
-
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 (mostly) ignored 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. 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> Link: https://lore.kernel.org/r/20230302144732.1903781-18-u.kleine-koenig@pengutronix.deReviewed-by:
Hans de Goede <hdegoede@redhat.com> 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20230302144732.1903781-11-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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. 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 (mostly) ignored 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. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Hans de Goede authored
When support for instantiating an i2c-client for the fuel-gauge was added for the Windows based Yoga Book YB1-X91F/L models, the assumption was made that this would apply to the Android based YB1-X90F/L models too. But these have a completely different BIOS with completely different DMI strings. Update the existing YB1-X91 support to reflect that it only applies to the YB1-X91F/L models. Cc: Yauhen Kharuzhy <jekhor@gmail.com> Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230301092331.7038-15-hdegoede@redhat.com
-
Hans de Goede authored
The Yoga Tablet 2 1050/830 series have a HALL sensor for detecting when their (optional) case/cover is closed over the screen. Their Windows counterparts (alsmost the same HW, different BIOS) model this as a LID switch. Add support for reporting this as a LID switch on the Android models too. Signed-off-by:
-
Hans de Goede authored
The YT3 uses an TI LP8557 LED backlight controller, the LP8557's PWM input is connected to a PWM output coming from the LCD panel's controller. The Android kernel has a hack in the i915 driver to write the non-standard DSI reg 0x51 with the desired level to set the duty-cycle of the LCD's PWM. To avoid having to have a similar hack in the mainline kernel program instantiate an i2c-client for the LP8557 with platform-data to have the LP8557 to directly set the level (ignoring its PWM input), this allows backlight brightness control through a backlight device registered by the lp855x_bl driver. Signed-off-by:
-
Hans de Goede authored
Add the necessary info to instantiate the I2C device for the touchscreen on Lenovo Yoga Tab 3 Pro YT3-X90F tablets. Signed-off-by:
-
Hans de Goede authored
The Peaq C1010 tablet has a special "Dolby" button. This button has a WMI interface, but this is broken in several ways: 1. It only supports polling 2. The value read on polling goes from 0 -> 1 for one poll on both edges of the button, with no way to tell which edge causes the poll to return 1. 3. It uses a non unique GUID (it uses the Microsoft docs WMI example GUID). There currently is a WMI driver for this, but it uses several kludges to work around these issues and is not entirely reliable due to 2. Replace the unreliable WMI driver by using the x86-android-tablets code to instantiate a gpio_keys device for this. Signed-off-by:
-
Hans de Goede authored
Add gpio_keys instantation support to x86_android_tablet_init(), to avoid this having to be repeated in various x86_dev_info.init() functions. Signed-off-by:
-
Hans de Goede authored
All that remains now in x86-android-tablets-main.c is info for other (non Asus / Lenovo) tablets. Rename it to other.c to reflect this. Signed-off-by:
-
Hans de Goede authored
Move the info for the Lenovo tablets to their own lenovo.c file. Signed-off-by:
-
Hans de Goede authored
Move the info for the Asus tablets to their own asus.c file. Signed-off-by:
-
Hans de Goede authored
Move the shared power-supply fw-nodes and related files to a new separate shared-psy-info.c file. Signed-off-by:
-
Hans de Goede authored
In order to have a single MODULE_DEVICE_TABLE(dmi, ...), while allowing splitting the board descriptions into multiple files, add a new separate file for the DMI match table. Signed-off-by:
-
Hans de Goede authored
Move the helpers to get IRQs + GPIOs as well as the core code for instantiating all the devices missing from ACPI into a new core.c file. Signed-off-by:
-
Hans de Goede authored
Move the x86-android-tablets code into its own subdir, this is a preparation patch for splitting the somewhat large file into multiple smaller files. Signed-off-by:
-
Hans de Goede authored
The Acer Iconia One 7 B1-750 is a x86 ACPI tablet which ships with Android x86 as factory OS. Its DSDT contains a bunch of I2C devices which are not actually there, causing various resource conflicts. Enumeration of these is skipped through the acpi_quirk_skip_i2c_client_enumeration(). Add support for manually instantiating the I2C + other devices which are actually present on this tablet by adding the necessary device info to the x86-android-tablets module. Signed-off-by:
-
Srinivas Pandruvada authored
User space can get the API version using IOCTL ISST_IF_GET_PLATFORM_INFO. This information can be used to get IOCTLs supported by the kernel driver. This version is hardcoded in the driver. Allow the registered client to specify the supported API version. In this way a registered client can specify a higher API version to extend IOCTL set. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20230211063257.311746-5-srinivas.pandruvada@linux.intel.comSigned-off-by:
-
Srinivas Pandruvada authored
The common IOCTL handler has a predefined list of IOCTLs it can handle. There is no default handler, if there is no match. Allow a client driver to define their own version of default IOCTL callback. In this way the default handling is passed to the client drivers to handle. With the introduction of TPMI target, IOCTL list is extended. The additional TPMI specific IOCTLs will be passed to the TPMI client driver default IOCTL handler. Signed-off-by:
-
Srinivas Pandruvada authored
Add TPMI as one of the device type which can be registered with ISST common driver. Signed-off-by:
-
Hans de Goede authored
Initialize shift variable in mlxplat_mlxcpld_verify_bus_topology() to 0 to avoid the following compile error: drivers/platform/x86/mlx-platform.c:6013 mlxplat_mlxcpld_verify_bus_topology() error: uninitialized symbol 'shift'. Fixes: 50b823fd ("platform: mellanox: mlx-platform: Move bus shift assignment out of the loop") Cc: Vadim Pasternak <vadimp@nvidia.com> Cc: Michael Shych <michaelsh@nvidia.com> Signed-off-by:
-
Daniel Scally authored
Add the INT347E GPIO lookup table to the board data for the Surface Go 3. This is necessary to allow the ov7251 IR camera to probe properly on that platform. Signed-off-by:
Daniel Scally <dan.scally@ideasonboard.com> Link: https://lore.kernel.org/r/20230302102611.314341-1-dan.scally@ideasonboard.comReviewed-by:
-
Srinivas Pandruvada authored
Fix warning displayed for "make W=1" for kernel documentation. Signed-off-by:
-
Randy Dunlap authored
REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". Fixes: ef0f6226 ("platform/x86: mlx-platform: Add physical bus number auto detection") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Vadim Pasternak <vadimp@mellanox.com> Cc: Darren Hart <dvhart@infradead.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <markgross@kernel.org> Cc: platform-driver-x86@vger.kernel.org Link: https://lore.kernel.org/r/20230226053953.4681-7-rdunlap@infradead.orgSigned-off-by:
-
Randy Dunlap authored
REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". For NVSW_SN2201, select REGMAP_I2C instead of depending on it. Fixes: c6acad68 ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface") Fixes: 5ec4a8ac ("platform/mellanox: Introduce support for Mellanox register access driver") Fixes: 62f9529b ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices") Fixes: 662f2482 ("platform/mellanox: Add support for new SN2201 system") Signed-off-by:
-
Srinivas Pandruvada authored
Fix warning: drivers/platform/x86/intel/tpmi.c:253 tpmi_create_device() warn: 'feature_vsec_dev' was already freed. If there is some error, feature_vsec_dev memory is freed as part of resource managed call intel_vsec_add_aux(). So, additional kfree() call is not required. Reordered res allocation and feature_vsec_dev, so that on error only res is freed. Reported-by:
Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/platform-driver-x86/Y%2FxYR7WGiPayZu%2FR@kili/T/#u Fixes: 47731fd2 ("platform/x86/intel: Intel TPMI enumeration driver") Signed-off-by:
-
