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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
.probe_new() doesn't get the i2c_device_id * parameter, so determine
that explicitly in the probe function.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Ido Schimmel <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
The function xilinxfb_release() returns zero unconditionally. Make it
return void. There is no semantic change, the only effect is that it
becomes obvious that the driver's .remove() callback always returns zero.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Even in the presence of problems (here: regulator_disable() might fail),
it's important to unregister all resources acquired during .probe() and
disable the device (i.e. DMA activity) because even if .remove() returns
an error code, the device is removed and the .remove() callback is never
called again later to catch up.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Fixes: 611097d5da ("fbdev: da8xx: add support for a regulator")
Move the board info structures from the glue drivers to the
common library and hence deduplicate configuration data.
For the Intel Braswell case the ACPI version should be used.
Because switch to ACPI/PCI is done in BIOS while quite likely
the rest of AML code is the same, meaning similar issue might
be observed. There is no bug report due to no PCI enabled device
in the wild, Andy thinks, and only reference boards can be tested,
so nobody really cares about Intel Braswell PCI case.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Declarations for static symbols are useless code repetition (unless
there are cyclic dependencies).
Reorder some functions and variables which allows to get rid of 7
forward declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Declarations for static symbols are useless code repetition (unless
there are cyclic dependencies).
Reorder some functions and variables which allows to get rid of 42
forward declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Declarations for static symbols are useless repetition unless there are
cyclic dependencies.
Reorder the functions and variables to get rid of 4 forward declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Make use of the cpp symbol DRIVER_NAME to set the driver's name and use
it instead of all explicit usages of the same string. Also make use of
it instead of sis5595_driver.driver.name which breaks a cyclic dependency
between sis5595_probe() and sis5595_driver that in the next commit allows
to drop some forward declarations. For an amd64 allyesconfig this even
reduces the size of the driver by 3 bytes.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Declarations for static symbols are useless repetition unless there are
cyclic dependencies.
Reorder the functions and variables to get rid of 6 forward declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Make use of the cpp symbol DRIVER_NAME to set the driver's name and use
it instead of all explicit usages of the same string. Also make use of
it instead of sis5595_driver.driver.name which breaks a cyclic dependency
between sis5595_probe() and sis5595_driver that in the next commit allows
to drop some forward declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Several drivers manually register a devm handler to disable their clk.
Convert them to devm_clk_get_enabled().
Acked-by: Guenter Roeck <[email protected]>
Reviewed-by: Nuno Sá <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Declarations for static symbols are useless repetition unless there are
cyclic dependencies.
Reorder the functions and variables to get rid of 5 forward declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Make use of the cpp symbol DRIVER_NAME to set the driver's name and use
it instead of all explicit usages of the same string. Also make use of
it instead of vt8231_driver.driver.name which breaks a cyclic dependency
between vt8231_probe() and vt8231_driver that in the next commit allows
to drop some forward declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Declarations for static symbols are useless repetition unless there are
cyclic dependencies.
Reorder the functions and variables to get rid of 6 forward declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Make use of the cpp symbol DRIVER_NAME to set the driver's name and also
as name for devm_request_region(). While at it add a module alias using
the new define.
This is a preparation for the next cleanup commit that removes a cyclic
dependency between pc87360_driver (which references pc87360_probe in
.probe) and pc87360_probe() (which used pc87360_driver.driver.name).
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Having the driver struct at the end of the file isn't only more usual, it
also allows to drop a few forward declarations which are just useless
repetition.
While at it also move the MODULE_... macros to the end of the file.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
sa11x0_drv_pcmcia_legacy_remove() returns zero unconditionally. Letting it
return void instead makes it easier to see in the caller that there is no
error to handle.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Dominik Brodowski <[email protected]>
By swapping the definition of skl_int3472_discrete_remove() and
skl_int3472_discrete_probe() the forward declaration of the former can
be dropped. This is a good thing as it removes code duplication.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Daniel Scally <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Usually it's not necessary to declare static functions if the symbols are
in the right order. Moving the definition of tsi_eth_driver down in the
compilation unit allows to drop two such declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Quite a few of the functions and other symbols defined in this driver had
forward declarations. They can all be dropped after reordering them.
This saves a few lines of code and reduces code duplication.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
After the result of the previous conversion is read the chip
automatically starts a new conversion and doesn't accept new i2c
transfers until this conversion is completed which makes the function
return failure.
So add an early return iff the programming of the new address isn't
needed. Note this will not fix the problem in general, but all cases
that are currently used. Once this changes we get the failure back, but
this can be addressed when the need arises.
Fixes: 69548b7c2c ("iio: adc: ltc2497: split protocol independent part in a separate module ")
Reported-by: Meng Li <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Tested-by: Denys Zagorui <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Cameron <[email protected]>
There is no cyclic dependency between gpio_twl4030_probe() and
gpio_twl4030_remove(), so by moving the latter before the former the
forward declaration can be dropped.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Usually it's not necessary to declare static functions if the symbols are
in the right order. Moving the definition of acpi_wmi_driver down in the
compilation unit allows to drop two such declarations.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Commit ed5c2f5fd1 ("i2c: Make remove callback return void") changed
the prototype of ams_i2c_remove() but failed to adapt the declaration.
Catch up and fix the declaration accordingly.
Fixes: ed5c2f5fd1 ("i2c: Make remove callback return void")
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Signed-off-by: Wolfram Sang <[email protected]>
pm_runtime_get_sync() returning 1 also means the device is powered. So
resetting the chip registers in .remove() is possible and should be
done.
Reported-by: Dan Carpenter <[email protected]>
Fixes: d98bdd3a5b ("i2c: imx: Make sure to unregister adapter on remove()")
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Oleksij Rempel <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
The timer units in the stm32mp15x CPUs have interrupts, depending on the
timer flavour either one "global" or four dedicated ones. Add the irqs
to the timer units on stm32mp15x.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Alexandre Torgue <[email protected]>
The single difference between returning 0 and returning an error code in
a platform remove callback is that in the latter case the platform core
emits a warning about the error being ignored.
If reset_control_assert() fails there is already a warning, so suppress
the more generic (and less helpful) by returning 0 in
tegra_xusb_padctl_remove().
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
If for whatever reasons pm_runtime_resume_and_get() fails and .remove() is
exited early, the i2c adapter stays around and the irq still calls its
handler, while the driver data and the register mapping go away. So if
later the i2c adapter is accessed or the irq triggers this results in
havoc accessing freed memory and unmapped registers.
So unregister the software resources even if resume failed, and only skip
the hardware access in that case.
Fixes: 588eb93ea4 ("i2c: imx: add runtime pm support to improve the performance")
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Oleksij Rempel <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
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 <[email protected]>
Reviewed-by: Jeremy Kerr <[email protected]>
Reviewed-by: Benjamin Mugnier <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Crt Mori <[email protected]>
Reviewed-by: Heikki Krogerus <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Marek Behún <[email protected]> # for leds-turris-omnia
Acked-by: Andy Shevchenko <[email protected]>
Reviewed-by: Petr Machata <[email protected]> # for mlxsw
Reviewed-by: Maximilian Luz <[email protected]> # for surface3_power
Acked-by: Srinivas Pandruvada <[email protected]> # for bmc150-accel-i2c + kxcjk-1013
Reviewed-by: Hans Verkuil <[email protected]> # for media/* + staging/media/*
Acked-by: Miguel Ojeda <[email protected]> # for auxdisplay/ht16k33 + auxdisplay/lcd2s
Reviewed-by: Luca Ceresoli <[email protected]> # for versaclock5
Reviewed-by: Ajay Gupta <[email protected]> # for ucsi_ccg
Acked-by: Jonathan Cameron <[email protected]> # for iio
Acked-by: Peter Rosin <[email protected]> # for i2c-mux-*, max9860
Acked-by: Adrien Grassein <[email protected]> # for lontium-lt8912b
Reviewed-by: Jean Delvare <[email protected]> # for hwmon, i2c-core and i2c/muxes
Acked-by: Corey Minyard <[email protected]> # for IPMI
Reviewed-by: Vladimir Oltean <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Sebastian Reichel <[email protected]> # for drivers/power
Acked-by: Krzysztof Hałasa <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
All platforms that provide a teardown callback return 0. New users are
supposed to not make use of platform support, so there is no
functionality lost.
This patch is a preparation for making i2c remove callbacks return void.
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
The mutex might still be in use until the devm cleanup callback
devm_led_classdev_flash_release() is called. This only happens some time
after lm3601x_remove() completed.
Fixes: e63a744871 ("leds: lm3601x: Convert class registration to device managed")
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Returning an error value from an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference. The device goes away anyhow and the devm cleanups are
called.
As lm3697_remove() already emits an error message on failure and the
additional error message by the i2c core doesn't add any useful
information, don't pass the error value up the stack. Instead continue
to clean up and return 0.
This patch is a preparation for making i2c remove callbacks return void.
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
A remove callback that just returns 0 is equivalent to no callback at all
as can be seen in i2c_device_remove(). So simplify accordingly.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
The calculation:
val = (u64)NSEC_PER_SEC * LPC18XX_PWM_TIMER_MAX;
do_div(val, lpc18xx_pwm->clk_rate);
lpc18xx_pwm->max_period_ns = val;
is bogus because with NSEC_PER_SEC = 1000000000,
LPC18XX_PWM_TIMER_MAX = 0xffffffff and clk_rate < NSEC_PER_SEC this
overflows the (on lpc18xx (i.e. ARM32) 32 bit wide) unsigned int
.max_period_ns. This results (dependant of the actual clk rate) in an
arbitrary limitation of the maximal period. E.g. for clkrate =
333333333 (Hz) we get max_period_ns = 9 instead of 12884901897.
So make .max_period_ns an u64 and pass period and duty as u64 to not
discard relevant digits. And also make use of mul_u64_u64_div_u64()
which prevents all overflows assuming clk_rate < NSEC_PER_SEC.
Fixes: 841e6f90bb ("pwm: NXP LPC18xx PWM/SCT driver")
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
This has various upsides:
- It emits the symbolic name of the error code
- It is silent in the EPROBE_DEFER case and properly sets the defer reason
- It reduces the number of code lines slightly
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
I found these just from reading the reference manual and the driver
source. It's unclear to me if there are glitches when updating the ON
and OFF registers.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
The PWMs are expected to be functional until pwmchip_remove() is called.
So disable the clks only afterwards.
Fixes: 9e37a53eb0 ("pwm: sifive: Add a driver for SiFive SoC PWM")
Signed-off-by: Uwe Kleine-König <[email protected]>
Tested-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
.apply() assumes the clk to be for a given PWM iff the PWM is enabled.
So make sure this is the case when .probe() completes. And in .remove()
disable the according number of times.
This fixes a clk enable/disable imbalance, if some PWMs are already running
at probe time.
Fixes: 9e37a53eb0 (pwm: sifive: Add a driver for SiFive SoC PWM)
Signed-off-by: Uwe Kleine-König <[email protected]>
Tested-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
The clk is necessary for both register access and (enabled) operation of
the PWM. Instead of
clk_enable()
update_hw()
if pwm_got_enabled():
clk_enable()
elif pwm_got_disabled():
clk_disable()
clk_disable()
which is some cases only calls clk_enable() to immediately afterwards
call clk_disable again, do:
if (!prev_state.enabled)
clk_enable()
# clk enabled exactly once
update_hw()
if (!next_state.enabled)
clk_disable()
which is much easier.
Signed-off-by: Uwe Kleine-König <[email protected]>
Tested-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
For the period check and the initial calculations of register values there
is no hardware access needed. So delay enabling the clk a bit to simplify
the code flow a bit.
Signed-off-by: Uwe Kleine-König <[email protected]>
Tested-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
The lock is only to serialize access and update to user_count and
approx_period between different PWMs served by the same pwm_chip.
So the lock needs only to be taken during the check if the (chip global)
period can and/or needs to be changed.
Signed-off-by: Uwe Kleine-König <[email protected]>
Tested-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
There is only a single caller of pwm_sifive_enable() which only enables
or disables the clk. Put this implementation directly into
pwm_sifive_apply() which allows further simplification in the next
change.
There is no change in behaviour.
Signed-off-by: Uwe Kleine-König <[email protected]>
Tested-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Instead of explicitly using PWM_SIFIVE_PWMCMP0 + pwm->hwpwm *
PWM_SIFIVE_SIZE_PWMCMP for each access to one of the PWMCMP registers,
introduce a macro that takes the hwpwm id as parameter.
For the register definition using a plain 4 instead of the cpp constant
PWM_SIFIVE_SIZE_PWMCMP is easier to read, so define the offset macro
without the constant. The latter can then be dropped as there are no
users left.
Signed-off-by: Uwe Kleine-König <[email protected]>
Tested-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Returning an error in .remove() doesn't prevent a driver from being
unloaded. On unbind this only results in an error message, but the
device is remove anyhow.
I guess the author's idea of just returning -EPERM in .remove() was to
prevent unbinding a device. To achieve that set the suppress_bind_attrs
driver property and drop the useless .remove callback.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Christophe Leroy <[email protected]>
Acked-by: Scott Wood <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
The remove callback is only called after probe completed successfully.
In this case platform_set_drvdata() was called with a non-NULL argument
(in wlcore_probe()) and so wl is never NULL.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
When a remove platform device callback returns an error code, the driver
core emits an error message ("remove callback returned a non-zero value.
This will be ignored.\n") and still removes the device. As the driver
already emits a more specific error message, return 0 to suppress the
core's error message.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Tzung-Bi Shih <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Taking a lock at the beginning of .remove() doesn't prevent new readers.
With the existing approach it can happen, that a read occurs just when
the lock was taken blocking the reader until the lock is released at the
end of the remove callback which then accessed *data that is already
freed then.
To actually fix this problem the hwmon core needs some adaption. Until
this is implemented take the optimistic approach of assuming that all
readers are gone after hwmon_device_unregister() and
sysfs_remove_group() as most other drivers do. (And once the core
implements that, taking the lock would deadlock.)
So drop the lock, move the reset to after device unregistration to keep
the device in a workable state until it's deregistered. Also add a error
message in case the reset fails and return 0 anyhow. (Returning an error
code, doesn't stop the platform device unregistration and only results
in a little helpful error message before the devm cleanup handlers are
called.)
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
It's not allowed to quit remove early without cleaning up completely.
Otherwise this results in resource leaks that probably yield graver
problems later. Here for example some tasklets might survive the lifetime
of the sprd-dma device and access sdev which is freed after .remove()
returns.
As none of the device freeing requires an active device, just ignore the
return value of pm_runtime_get_sync().
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Baolin Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
This has several advantages:
- No need for manual undo of the two functions in the error path and
the remove function.
- Drops error handling in .remove()
Note that returning early in .remove() yields resource leaks that
often result in access of freed memory or unmapped registers later.
- Fixes a resource leak
request_mem_region allocates memory for the returned pointer that was
never freed.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
No source file but the driver itself includes the header containing the
platform data definition. The last user is gone since commit
8485adf17a ("ARM: imx: Remove imx device directory").
Move the remaining symbols directly into the driver and remove the then
unused header file.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
The only file that includes <linux/platform_data/video-imxfb.h> is the
imxfb driver. Drop all symbols that are unused there.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
No source file but the driver itself includes the header containing the
platform data definition. The last user is gone since commit
8485adf17a ("ARM: imx: Remove imx device directory").
So we can safely drop platform data support.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
The remove callback is only called after probe completed successfully.
In this case platform_set_drvdata() was called with a non-NULL argument
and so ecc_dev is never NULL.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
There is no in-tree machine that provides a struct twl4030_platform_data
since commit e92fc4f04a ("ARM: OMAP2+: Drop legacy board file for
LDP"). So assume dev_get_platdata() returns NULL in twl_probe() and
simplify accordingly.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
None of the in-tree instantiations of struct t7l66xb_platform_data
provides a disable callback. So better don't dereference this function
pointer unconditionally. As there is no user, drop it completely instead
of calling it conditional.
This is a preparation for making platform remove callbacks return void.
Fixes: 1f192015ca ("mfd: driver for the T7L66XB TMIO SoC")
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Up to now asic3_gpio_remove() returns zero unconditionally. This makes it
easier to see in the caller that there is no error to handle.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
The remove callback is only called after probe completed successfully.
In this case platform_set_drvdata() was called with a non-NULL argument
and so chip is never NULL.
Also note that returning an error code from a remove callback doesn't
result in the device staying bound. It's still removed and devm
callbacks are called.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
priv cannot be NULL because brcmstb_gpio_probe() calls
platform_set_drvdata() with a non-NULL argument, so the check for !priv can
be dropped.
Also remove the variable ret that is only used to hide a bit that in the
end zero is returned.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
There is no user of these callbacks. The motivation for this change is
to stop returning an error code from the remove callback.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Returning a non-zero value in a platform driver's remove callback only
results in an error message ("remove callback returned a non-zero value.
This will be ignored.", see platform_remove()), and then the device is
removed anyhow.
As there was just a WARN_ON triggered, return 0 to drop the follow up
warning. The latter output is hardly relevant after the big WARN splat.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
There is no machine providing a teardown callback, so drop the unused
code.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Returning an error code (here -EBUSY) from a remove callback doesn't
prevent the driver from being unloaded. The only effect is that an error
message is emitted and the driver is removed anyhow.
So instead drop the remove function (which is equivalent to returning zero)
and set the suppress_bind_attrs property to make it impossible to unload
the driver via sysfs.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Uwe Kleine-König