Rev E2 of the AM68 SK baseboard has updated the GPIO IO expander pins
functionality. To match the Rev E2 schematics, update existing IO expander
GPIO line names and the corresponding node which uses the expansion(exp1)
node.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Link: https://lore.kernel.org/r/20230315120934.16954-1-sinthu.raja@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
BeagleBoard.org BeaglePlay is an easy to use, affordable open source
hardware single board computer based on the Texas Instruments AM625
SoC that allows you to create connected devices that work even at long
distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L.
Expansion is provided over open standards based mikroBUS, Grove and
QWIIC headers among other interfaces.
This board family can be identified by the 24c32 eeprom:
[aa 55 33 ee 01 37 00 10 2e 00 42 45 41 47 4c 45 |.U3..7....BEAGLE|]
[50 4c 41 59 2d 41 30 2d 00 00 30 32 30 30 37 38 |PLAY-A0-..020078|]
https://beagleplay.org/https://git.beagleboard.org/beagleplay/beagleplay
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230316152143.2438928-3-nm@ti.com
Co-developed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
The "Smart Battery Selector" standard says that when writing
SelectorState (0x1), the nibbles which should not be modified
need to be masked with 0xff. This is necessary since in contrast
to a "Smart Battery Manager", the last three nibbles are writable.
Failing to do so might trigger the following cycle:
1. Host accidentally changes power source of the system (3rd nibble)
when selecting a battery.
2. Power source is invalid, Selector changes to another power source.
3. Selector notifies host that it changed the power source.
4. Host re-reads some batteries.
5. goto 1 for each re-read battery.
This loop might also be entered when a battery which is not present
is selected for SMBus access. In the end some workqueues fill up,
which causes the system to lockup upon suspend/shutdown.
Fix this by correctly masking the value to be written, and avoid
selecting batteries which are absent.
Tested on a Acer Travelmate 4002WLMi.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When removing custom query handlers, the handler might still
be used inside the EC query workqueue, causing a kernel oops
if the module holding the callback function was already unloaded.
Fix this by flushing the EC query workqueue when removing
custom query handlers.
Tested on a Acer Travelmate 4002WLMi
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
According to the ACPI spec part 5.6.4.1.2, EC query handlers discovered
thru ACPI should not be removed when a driver removes his custom query
handler. On the Acer Travelmate 4002WLMi for example, such a query
handler is used as a fallback to handle the EC SMBus alert when no driver
is present.
Change acpi_ec_remove_query_handlers() so that only custom query
handlers are removed then remove_all is false. Query handlers discovered
thru ACPI will still get removed when remove_all is true, which happens
on device removal. Also add a simple check to ensure that
acpi_ec_add_query_handler() is always called with either handle or func
being set, since custom query handlers are detected based whether
handlers->func is set or not.
Tested on a Acer Travelmate 4002WLMi.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
[ rjw: Comment adjustment ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
TI's K3 platform uses McASP as the digital audio interface on the SoCs.
AM62-SK, AM62-LP-SK and AM62A-SK also use the TLV320AIC3106 codec with a
3.5mm jack for analog audio input and output.
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20230313-mcasp_upstream-v10-3-94332149657a@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
* various ivpu fixes
* fix nouveau backlight registration
* fix buddy allocator in 32-bit systems
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEchf7rIzpz2NEoWjlaA3BHVMLeiMFAmQll8UACgkQaA3BHVML
eiOeCAgAuZ4njGFuTDPbSj8xvMSTzBhCK/q452MosuIL8XBa3wMJy8SsjpGP5yA5
uUBCDO9ZdIw1ZVvUfmSR9X+Q0L3HSQEGax9jgk67Hj0bGJlVhEqVvifBrhCum+Jd
GUHRYPuNCSrlGrtlQEtCd2puZ+pS5IJoClunJ4wTdO/hwXmvaRF8QMWkn7Y9GWKs
JcNY5kd2ZeBw05XcSO9A89vrQMmqAbAjHfMEdwqZu22C9gZ8dlnPUxpqLHfg5tkz
XQj7PWQK4vQzvjBA70vS6sNcjpiS6i7FekWzAL/3fb5BQHRZx1RTOPcruQcwE+O5
bKKsB09JSGgg5M4noJQ4I/bXIWXnjA==
=mQp3
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2023-03-30' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Short summary of fixes pull:
* various ivpu fixes
* fix nouveau backlight registration
* fix buddy allocator in 32-bit systems
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230330141006.GA22908@linux-uq9g
Enable drivers used on BeaglePlay[1]:
* MDIO_GPIO driver to workaround erratum i2329, DP83TD510 SPE phy
(enabled in-kernel to ease usage)
* TPS65219 PMIC, regulator as built-in for sd boot and power button
as modules. (note: this is also used by am62x-lp-sk as well)
* BQ32K battery backedup RTC and the K3 RTC drivers as modules
* OMAP2 SPI driver as module for accessing mikrobus
bloat-o-meter reports after this change (v6.3-rc1, clang 17.0.0):
add/remove: 63/2 grow/shrink: 3/0 up/down: 17660/-16 (17644)
[...]
Total: Before=27747186, After=27764830, chg +0.06%
[1] https://beagleplay.org
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230316152143.2438928-4-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Since commit 31c8db2c4f ("ice: implement devlink reinit action"), the ice
driver does support driver re-initialization via devlink reload. Remove the
stale comment indicating that the driver lacks this support from the
ice_devlink_ops structure.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Cc: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
The out-of-tree driver is hosted on SourceForge, as this does not apply
to the kernel driver remove references to it. Also do some minor
formatting changes around this section.
Suggested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Update the email address for support to use Intel Wired LAN, the mailing
list used for kernel development.
Suggested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
drm/i915 fixes for v6.3-rc5:
- Fix PMU support by reusing functions with sysfs
- Fix a number of issues related to color, PSR and arm/noarm
- Fix state check related to ICL PHY ownership check in TC-cold state
- Flush lmem contents after construction
- Fix hibernate oops related to DPT BO
- Fix perf stream error path wakeref balance
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87355m4gtm.fsf@intel.com
A collection of small fixes:
- A potential deadlock fix for USB-audio, involving some change
in PCM core side
- A regression fix for probes of USB-audio devices with the
vendor-specific PCM format bits
- Two regression fixes for the old YMFPCI driver
- A few HD-audio quirks as usual
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmQkN0cOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8xmhAAwKf45KZWeuWs/HtlnJe7tyaS88zyAjdw2JY0
+WiZsjIFruOC2NwHtrIBmpqC8baaCzUTEveorVo/5mHt1KsJmwl5Necz/2CkGmCQ
VfAaaDoMMxh75VIod69i6vAY6L5tYjyNOjKrsYixdR90mtTlgCxhZumoAwoB5/2x
TJZUL9cmRnHm3V/9eCzb0UOOPYVr/WRleUMovr31uuHHp/owNAKzPh960l+hax9/
Tf1nHPVtq17x/JKagSTKIyNgK53mwT8t+86S5gGgGiVdqGtj5mfxoRdgyRMR17mr
WoL1bNX4V6Y/CbRTBxmHqWYb/RHLWvq5fcJRP1BGI/nMds0hCSW2/4ywKZYqgllr
sHs1h3HJVl94X/sA5bCHFTB4EQC6n3Ci+TZmIbeAsMaTPq9E1M6jUB+6m3qKfnGk
7YW09vx460jy8X2rK3jdq7EAaCTOaiJzcGXLYlk6G2lyynRHVOh7MGp3opKHZB9k
9LlIdWjchpOZfeizhcpmvUegVKfS2JyIQEIyhGc9StNhFlPGj8+aRHX/U1D0W9op
Ad1cnieSiN5b8+MOFJO4LeqOQ+yHYV1WJRNjCRztna2x5j/Hif8aV35JRLoGesnm
UYcPcjTiWZVreFYbuKcCOkYRWN8FR9xUkLR1Hxj+BuenvKq5SEZINEokiuQddb2b
TUS33XQ=
=T5LZ
-----END PGP SIGNATURE-----
Merge tag 'sound-6.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of small fixes:
- A potential deadlock fix for USB-audio, involving some change in
PCM core side
- A regression fix for probes of USB-audio devices with the
vendor-specific PCM format bits
- Two regression fixes for the old YMFPCI driver
- A few HD-audio quirks as usual"
* tag 'sound-6.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda/realtek: Add quirk for Lenovo ZhaoYang CF4620Z
ALSA: ymfpci: Fix BUG_ON in probe function
ALSA: ymfpci: Create card with device-managed snd_devm_card_new()
ALSA: usb-audio: Fix regression on detection of Roland VS-100
ALSA: hda/realtek: Fix support for Dell Precision 3260
ALSA: usb-audio: Fix recursive locking at XRUN during syncing
ALSA: hda/conexant: Partial revert of a quirk for Lenovo
ALSA: hda/realtek: Add quirks for some Clevo laptops
* Make sure to always invalidate the last page of an inode straddling
inode->i_size to avoid data inconsistencies with appended data when
the device zone write granularity does not match the page size.
* Do not propagate iomap -ENOBLK error to userspace and use -EBUSY
instead.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSRPv8tYSvhwAzJdzjdoc3SxdoYdgUCZCV+vgAKCRDdoc3SxdoY
dhtrAQCYLbuQPHM5WwO9oJPnKYGgDjOBQbcDC0hjTG3rLjquHgD+O16QHO02raDk
++C5sl6r22jK1m8GqOckfJ/wdESgCQM=
=Lmth
-----END PGP SIGNATURE-----
Merge tag 'zonefs-6.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs
Pull zonefs fixes from Damien Le Moal:
- Make sure to always invalidate the last page of an inode straddling
inode->i_size to avoid data inconsistencies with appended data when
the device zone write granularity does not match the page size.
- Do not propagate iomap -ENOBLK error to userspace and use -EBUSY
instead.
* tag 'zonefs-6.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs:
zonefs: Do not propagate iomap_dio_rw() ENOTBLK error to user space
zonefs: Always invalidate last cached page on append write
This reverts commit df622729dd as it introduces a use-after-free,
which isn't easy to fix without going back to the design drawing board.
Reported-by: Danilo Krummrich <dakr@redhat.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
This reverts commit 97804a133c, as it builds on top of df622729dd
("drm/scheduler: track GPU active time per entity") which needs to be
reverted, as it introduces a use-after-free.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
drm_gem_prime_mmap() takes a reference on the GEM object, but before that
drm_gem_mmap_obj() already takes a reference, which will be leaked as only
one reference is dropped when the mapping is closed. Drop the extra
reference when dma_buf_mmap() succeeds.
Cc: stable@vger.kernel.org
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
"Digitizer" is a generic usage that may be used by various devices but
which is particularly used by non-display pen tablets. This patch adds the
usage to the list of values matched by the IS_INPUT_APPLICATION() macro
that determines if an input device should be allocated or not.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Link: https://lore.kernel.org/r/20221019151832.44522-1-jason.gerecke@wacom.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
This reverts commit b7d9aae404.
With the Qualcomm remoteproc driver now modified to use a carveout
memory region in 57f72170a2 ("remoteproc: qcom_q6v5_mss: Use a
carveout to authenticate modem headers"), we can reinstate c44094eee3
("arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()")
which relaxes the arm64 implementation of arch_dma_prep_coherent() to
perform only a data cache clean operation, rather than a
clean-and-invalidate.
Signed-off-by: Will Deacon <will@kernel.org>
When an overflow occurs in the PRI queue, the SMMU toggles the overflow
flag in the PROD register. To exit the overflow condition, the PRI thread
is supposed to acknowledge it by toggling this flag in the CONS register.
Unacknowledged overflow causes the queue to stop adding anything new.
Currently, the priq thread always writes the CONS register back to the
SMMU after clearing the queue.
The writeback is not necessary if the OVFLG in the PROD register has not
been changed, no overflow has occured.
This commit checks the difference of the overflow flag between CONS and
PROD register. If it's different, toggles the OVACKFLG flag in the CONS
register and write it to the SMMU.
The situation is similar for the event queue.
The acknowledge register is also toggled after clearing the event
queue but never propagated to the hardware. This would only be done the
next time when executing evtq thread.
Unacknowledged event queue overflow doesn't affect the event
queue, because the SMMU still adds elements to that queue when the
overflow condition is active.
But it feel nicer to keep SMMU in sync when possible, so use the same
way here as well.
Signed-off-by: Tomas Krcka <krckatom@amazon.de>
Link: https://lore.kernel.org/r/20230329123420.34641-1-tomas.krcka@gmail.com
Signed-off-by: Will Deacon <will@kernel.org>
For allowing the build without CONFIG_PM, add definitions of dummy
functions for snd_ac97_suspend() and snd_ac97_resume() without
CONFIG_PM, too.
Link: https://lore.kernel.org/r/20230330132847.12882-1-tiwai@suse.de
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Tasos Sahanidis <tasos@tasossah.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The command allocated to set exit latency LPM values need to be freed in
case the command is never queued. This would be the case if there is no
change in exit latency values, or device is missing.
Reported-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Link: https://lore.kernel.org/linux-usb/24263902-c9b3-ce29-237b-1c3d6918f4fe@alu.unizg.hr
Tested-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Fixes: 5c2a380a5a ("xhci: Allocate separate command structures for each LPM command")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20230330143056.1390020-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 4c2604a9a6.
Asynch probe caused regression in a setup with both Renesas and Intel xHC
controllers. Devices connected to the Renesas disconnected shortly after
boot. With Asynch probe the busnumbers got interleaved.
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 2
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3
xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 4
Reason why this commit causes regression is still unknown, but revert it
while debugging the issue.
Fixes: 4c2604a9a6 ("usb: xhci-pci: Set PROBE_PREFER_ASYNCHRONOUS")
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/linux-usb/20230307132120.5897c5af@deangelis.fenrir.org.uk
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20230330143056.1390020-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Previously the quirk was skipped when no iommu was present. The same
rationale for skipping the quirk also applies in the iommu.passthrough=1
case.
Skip applying the XHCI_ZERO_64B_REGS quirk if the device's iommu domain is
passthrough.
Fixes: 12de0a35c9 ("xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers")
Cc: stable <stable@kernel.org>
Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20230330143056.1390020-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
