linux/drivers/staging/olpc_dcon, branch master

staging: olpc_dcon: Remove driver marked as broken since 2022

2024-10-16T08:01:30Z

Andres Salomon contributed this driver in 2010. The following reasons lead to the removal: - This driver generates maintenance workload - Kconfig still depends on BROKEN since 2022. Link: https://lore.kernel.org/all/Yqw4DynMEtAcZVim@kroah.com/ Signed-off-by: Philipp Hortmann Link: https://lore.kernel.org/r/20241013172759.7524-1-philipp.g.hortmann@gmail.com Signed-off-by: Greg Kroah-Hartman

staging: olpc_dcon: Drop explicit initialization of struct i2c_device_id::driver_data to 0

2024-10-09T09:54:49Z

These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20240920153430.503212-16-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman

staging: olpc_dcon: Use backlight power constants

2024-08-13T09:26:13Z

Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by: Thomas Zimmermann Cc: Jens Frederich Cc: Jon Nettleton Cc: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20240731130130.1148153-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman

staging: olpc_dcon: Remove I2C_CLASS_DDC support

2023-10-27T11:10:05Z

olpc_dcon is the only remaining i2c client device driver declaring I2C_CLASS_DDC support after the legacy eeprom driver has been removed. olpc_dcon is only used on olpc devices, connected to an i2c adapter driven by scx200_acb. This adapter driver declares support for I2C_CLASS_HWMON and I2C_CLASS_SPD. Therefore we can safely drop I2C_CLASS_DDC support in olpc_dcon. That's the last step before I2C_CLASS_DDC can be removed in general. This patch is solely based on documentation, and I don't have an olpc device for testing. Therefore some testing would be appreciated before patch is applied. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/da3070d9-e016-4167-843f-a08d5b2dc1fe@gmail.com Signed-off-by: Greg Kroah-Hartman

staging: olpc_dcon: Switch i2c driver back to use .probe()

2023-05-28T09:15:27Z

After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230524151646.486847-5-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman

staging: olpc_dcon: Convert to i2c's .probe_new()

2022-11-22T12:23:25Z

The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20221118224540.619276-571-uwe@kleine-koenig.org Signed-off-by: Greg Kroah-Hartman

i2c: Make remove callback return void

2022-08-16T10:46:26Z

The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin Reviewed-by: Jeremy Kerr Reviewed-by: Benjamin Mugnier Reviewed-by: Javier Martinez Canillas Reviewed-by: Crt Mori Reviewed-by: Heikki Krogerus Acked-by: Greg Kroah-Hartman Acked-by: Marek Behún # for leds-turris-omnia Acked-by: Andy Shevchenko Reviewed-by: Petr Machata # for mlxsw Reviewed-by: Maximilian Luz # for surface3_power Acked-by: Srinivas Pandruvada # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil # for media/* + staging/media/* Acked-by: Miguel Ojeda # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli # for versaclock5 Reviewed-by: Ajay Gupta # for ucsi_ccg Acked-by: Jonathan Cameron # for iio Acked-by: Peter Rosin # for i2c-mux-*, max9860 Acked-by: Adrien Grassein # for lontium-lt8912b Reviewed-by: Jean Delvare # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard # for IPMI Reviewed-by: Vladimir Oltean Acked-by: Dmitry Torokhov Acked-by: Sebastian Reichel # for drivers/power Acked-by: Krzysztof Hałasa Signed-off-by: Uwe Kleine-König Signed-off-by: Wolfram Sang

Merge 5.19-rc3 into staging-next

2022-06-20T06:59:23Z

This resolves the merge issue with: drivers/staging/r8188eu/os_dep/ioctl_linux.c Reported-by: Stephen Rothwell Signed-off-by: Greg Kroah-Hartman

staging: olpc_dcon: Replace flush_scheduled_work() with flush_work().

2022-06-10T12:47:45Z

Since "struct dcon_priv" is per a device struct, I assume that dcon_set_source_sync() needs to wait for only one work associated with that device. Therefore, wait for only that work using flush_work(). Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/r/a973969d-cfd0-adc8-2651-d299199dbd7b@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman

staging: olpc_dcon: mark driver as broken

2022-06-10T07:09:47Z

The commit eecb3e4e5d9d ("staging: olpc_dcon: add OLPC display controller (DCON) support") added this driver in 2010, and has been in staging since then. It was marked as broken at some point because it didn't even build but that got removed once the build issues were addressed. But it seems that the work to move this driver out of staging has stalled, the last non-trivial change to fix one of the items mentioned in its todo file was commit e40219d5e4b2 ("staging: olpc_dcon: allow simultaneous XO-1 and XO-1.5 support") in 2019. And even if work to destage the driver is resumed, the fbdev subsystem has been deprecated for a long time and instead it should be ported to DRM. Now this driver is preventing to land a kernel wide change, that makes the num_registered_fb symbol to be private to the fbmem.c file. So let's just mark the driver as broken. Someone can then work on making it not depend on the num_registered_fb symbol, allowing to drop the broken dependency again. Suggested-by: Sam Ravnborg Acked-by: Thomas Zimmermann Signed-off-by: Javier Martinez Canillas Link: https://lore.kernel.org/r/20220609223424.907174-1-javierm@redhat.com Signed-off-by: Greg Kroah-Hartman