ack
return void") at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
tags/bus_remove_return_void-5.15
(see https://lore.kernel.org/lkml/ypkwqwf0dukng...@kroah.com).
It would be great if this could be merged into the drm tree with the
above diff squashed into the merge commit.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
in reply to the last request). To make this semantic obvious
rename the function.
Signed-off-by: Uwe Kleine-König
---
Documentation/driver-api/pwm.rst | 6 +++-
drivers/clk/clk-pwm.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c | 4 +--
drivers/input/misc
Hello Thierry,
On Tue, Apr 06, 2021 at 01:16:31PM +0200, Thierry Reding wrote:
> On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote:
> > Given that lowlevel drivers usually cannot implement exactly what a
> > consumer requests with pwm_apply_state() there is some ro
From: Uwe Kleine-König https://lists.freedesktop.org/mailman/listinfo/dri-devel
us Walleij
Signed-off-by: Uwe Kleine-König
---
drivers/amba/bus.c | 5 ++---
drivers/char/hw_random/nomadik-rng.c | 3 +--
drivers/dma/pl330.c| 3 +--
drivers/gpu/drm/pl111/pl111_drv.c | 4 +---
drivers
Hello,
On Tue, Jan 26, 2021 at 05:08:40PM +, Suzuki K Poulose wrote:
> On 1/26/21 4:58 PM, Uwe Kleine-König wrote:
> > All amba drivers return 0 in their remove callback. Together with the
> > driver core ignoring the return value anyhow, it doesn't make sense to
>
otype
----
Uwe Kleine-König (5):
amba: Fix resource leak for drivers without .remove
amba: reorder functions
vfio: platform: simplify device removal
amba: Make the remove callback return void
amba: Make use of bus_type func
remove callback return void")
Signed-off-by: Uwe Kleine-König
---
Hello,
I guess I missed that driver during rebase as it was only introduced in
the last merge window. Sorry for that.
I'm unsure what is the right thing to do now. Should I redo the pull
request (with this patch squashed int
Hello,
On Tue, Feb 02, 2021 at 02:53:50PM +0100, Uwe Kleine-König wrote:
> the following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
>
> Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
>
> are available in the Git repository at:
>
> https://git.pengutr
;re setting
> them for every struct device_driver, then there's no point doing that
> and they may as well be in the bus_type.
This is implemented in patch 5 already.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Indu
that is bisectable without build problems, but if Russell (who
already picked up the broken tag) considers his tree immutable and so
isn't willing to rebase, then picking up the patch is the way to go.
I suggest that Russell descides which option he wants to pick and tells
Greg to do the sa
Hello Russell, hello Greg,
On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux admin
> wrote:
> > On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Feb 04, 202
On Fri, Feb 05, 2021 at 11:18:17AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 05, 2021 at 10:37:44AM +0100, Uwe Kleine-König wrote:
> > Hello Russell, hello Greg,
> >
> > On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> > > On Thu, Feb 04, 202
0573d3fa4864 ("Merge branch 'devel-stable' of
git://git.armlinux.org.uk/~rmk/linux-arm into char-misc-next")
Signed-off-by: Uwe Kleine-König
---
On Fri, Feb 05, 2021 at 12:07:09PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 05, 2021 at 11:56:15AM +0100, Uwe Kleine-Köni
ap_dma, GFP_KERNEL);
> if (!info->screen_buffer) {
> - dev_err(&pdev->dev, "Failed to allocate video RAM: %d\n", ret);
> + dev_err(&pdev->dev, "Failed to allocate video RAM\n");
> ret = -ENOMEM;
>
Hello Christophe,
[dropping krzysztof...@poczta.fm from recipents, the address doesn't
seem to exist]
On Fri, May 07, 2021 at 09:11:19AM +0200, Christophe JAILLET wrote:
> Le 07/05/2021 à 07:05, Uwe Kleine-König a écrit :
> > On Thu, May 06, 2021 at 08:57:05PM +0200, Christophe
r
the individual drivers.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/Kconfig | 5 -
drivers/gpu/drm/ast/Kconfig | 2 ++
drivers/gpu/drm/gma500/Kconfig | 2 ++
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 ++
drivers/gpu/drm/i915/Kconfig
that returning an error code is a bad idea and ensures future
users behave accordingly.
Signed-off-by: Uwe Kleine-König
---
Hello,
if desired the change to arch/arm/mach-sa1100/collie.c can be split out
of this patch. The change of prototype then doesn't affect this driver
any more. There i
The remove callback is only called for devices that were probed
successfully before. As the matching probe function cannot complete
without error if dev->match_id != PS3_MATCH_ID_SOUND, we don't have to
check this here.
Signed-off-by: Uwe Kleine-König
---
sound/ppc/snd_ps3.c | 2 --
truct ps3_system_bus_driver::remove return void, too. All users
already unconditionally return 0, this commit makes it obvious that
returning an error code is a bad idea and ensures future users behave
accordingly.
Signed-off-by: Uwe Kleine-König
---
arch/powerpc/include/asm/ps3.h
On Fri, Nov 27, 2020 at 09:35:39AM +0100, Geert Uytterhoeven wrote:
> Hi Uwe,
>
> On Thu, Nov 26, 2020 at 6:03 PM Uwe Kleine-König
> wrote:
> > The remove callback is only called for devices that were probed
> > successfully before. As the matching probe function can
Hello Michael,
On Sat, Nov 28, 2020 at 09:48:30AM +0100, Takashi Iwai wrote:
> On Thu, 26 Nov 2020 17:59:50 +0100,
> Uwe Kleine-König wrote:
> >
> > The driver core ignores the return value of struct device_driver::remove
> > because there is only little that can b
7;m not sure about the purpose of the containing hardware, but I wonder
if it would be saner to not break probing of the device if adding the
PWM functionality fails. Ideally the driver would provide an mfd driver
that allows its components to be probed independently.
> i2c_set_clientdata(client, pdata);
&g
GPIO_MUX_GPIO4_SHIFT 6
>
> If you agree, you may consider to integrate this patch beforehand:
>
> https://github.com/shawnguo2/linux/commit/7cde887ffb3b27a36e77a08bee3666d14968b586
My preferred way here would be to add a prefix for the other constants.
It (IMHO) looks nicer and
GPI
On Thu, Dec 10, 2020 at 10:40:36PM +0800, Shawn Guo wrote:
> Hi Uwe,
>
> On Thu, Dec 10, 2020 at 9:05 PM Uwe Kleine-König
> wrote:
> > > > @@ -111,6 +118,8 @@
> > > >
> > > > #define SN_LINK_TRAINING_TRIES 10
> > >
.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 48 +--
1 file changed, 16 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 5cd2b2ebbbd3..6034e80c5b2e 100644
--- a
: Uwe Kleine-König
---
drivers/clk/clk-devres.c | 67 ++--
1 file changed, 50 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index f9d5b7334341..fb7761888b30 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk
When a driver keeps a clock prepared (or enabled) during the whole
lifetime of the driver, these helpers allow to simplify the drivers.
Reviewed-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Signed-off-by: Uwe Kleine-König
---
drivers/clk/clk-devres.c | 31 ++
include/linux
s390, sparc64
and x86_64 using an allmodconfig.
Best regards
Uwe
Uwe Kleine-König (16):
clk: generalize devm_clk_get() a bit
clk: Provide new devm_clk helpers for prepared and enabled clocks
hwmon: Make use of devm_clk_get_enabled()
iio: Make use of devm_clk_get_enabled()
hwrng: meson -
On Sat, Mar 19, 2022 at 06:29:36PM +, Jonathan Cameron wrote:
> On Mon, 14 Mar 2022 15:16:29 +0100
> Uwe Kleine-König wrote:
>
> > When a driver keeps a clock prepared (or enabled) during the whole
> > lifetime of the driver, these helpers allow to
Hi Rob,
On Mon, Feb 21, 2022 at 02:55:36PM +0100, Uwe Kleine-König wrote:
> On Thu, Feb 10, 2022 at 06:54:13PM +0100, Lucas Stach wrote:
> > Am Dienstag, dem 01.02.2022 um 11:35 -0600 schrieb Rob Herring:
> > > On Fri, Jan 28, 2022 at 06:58:29PM +0100, Uwe Kleine-König wrote:
&
pinctrl_pm_select_sleep_state(dev);
> + return err;
> + }
> +
> + return 0;
> }
> -#endif
>
> static const struct tegra_pwm_soc tegra20_pwm_soc = {
> .num_channels = 4,
> @@ -344,7 +387,10 @@ static const struct of_device_id tegra_pwm_of_match[]
Hello,
On Fri, May 14, 2021 at 12:01:42PM +0200, Uwe Kleine-König wrote:
> While working on a drm driver that doesn't need the i2c algobit stuff I
> noticed that DRM selects this code even tough only 8 drivers actually use
> it. While also only some drivers use i2c, keep the sele
Hello,
On Mon, Feb 21, 2022 at 12:53:58PM +0300, Dmitry Osipenko wrote:
> 21.02.2022 11:17, Uwe Kleine-König пишет:
> >> @@ -344,7 +387,10 @@ static const struct of_device_id tegra_pwm_of_match[]
> >> = {
> >> MODULE_DEVICE_TABLE(of, tegra_pwm_of_match);
&g
Hi Rob,
On Thu, Feb 10, 2022 at 06:54:13PM +0100, Lucas Stach wrote:
> Am Dienstag, dem 01.02.2022 um 11:35 -0600 schrieb Rob Herring:
> > On Fri, Jan 28, 2022 at 06:58:29PM +0100, Uwe Kleine-König wrote:
> > > On Fri, Jan 28, 2022 at 07:04:10AM -0600, Rob Herring wrote:
>
error to handle.
Also the return value of platform and spi remove callbacks is ignored
anyway and not freeing resources in .remove() is a bad idea.
Signed-off-by: Uwe Kleine-König
---
drivers/staging/fbtft/fbtft-core.c | 8 +---
drivers/staging/fbtft/fbtft.h | 6 --
2 files changed
Up to now s6e63m0_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/panel/panel
ady
return zero.
Given that there are quite some more patches of this type to create
before I can change the spi remove callback, I suggest the respecive
subsystem maintainers pick up these patches. There are no
interdependencies in this series.
Uwe Kleine-König (13):
drm/panel: s6e
Hello,
On Mon, Oct 11, 2021 at 03:27:41PM +0200, Uwe Kleine-König wrote:
> this series is part of my new quest to make spi remove callbacks return
> void. Today they return an int, but the only result of returning a
> non-zero value is a warning message. So it's a bad idea to ret
Up to now s6e63m0_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/panel/panel
error to handle.
Also the return value of platform and spi remove callbacks is ignored
anyway and not freeing resources in .remove() is a bad idea.
Signed-off-by: Uwe Kleine-König
---
drivers/staging/fbtft/fbtft-core.c | 8 +---
drivers/staging/fbtft/fbtft.h | 8 +---
2 files changed
#x27;s included
here, but I assume I was just too impatient and this one should be
ignored.
Full range-diff below.
Best regards
Uwe
Uwe Kleine-König (20):
drm/panel: s6e63m0: Make s6e63m0_remove() return void
gpio: max730x: Make __max730x_remove() return void
gpio: mc33880: Drop if with
happy with your patch set now.
> + period = period_max;
> + else
> + period = state->period;
> +
> + pre_div = DIV64_U64_ROUND_UP(period * pdata->pwm_refclk_freq,
> + (u64)NSEC_PER_SEC *
> (BACKLIGHT_SCALE_MAX + 1));
> + scale = div64_u64(period * pdata->pwm_refclk_freq,
> (u64)NSEC_PER_SEC * pre_div) - 1;
After thinking a while about this---I think I stumbled about this
calculation already in earlier revisions of this patch set---I think I
now understood it. I never saw something like this before because other
drivers with similar HW conditions would pick:
pre_div = div64_u64(period * pdata->pwm_refclk_freq,
(u64)NSEC_PER_SEC * (BACKLIGHT_SCALE_MAX + 1));
and then scale = BACKLIGHT_SCALE_MAX. This latter approach weights high
resolution of duty_cycle still higher over period exactness than your
approach. For me both approaches are fine.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
e_with_flags, but this shouldn't be a stopper here.
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
is fine.
So I think technically the patch is good, for me the question is if we
want to make new drivers of_pwm_xlate_with_flags for consistency even
though this would mean that the first argument has to be 0 for all
phandles. Thierry? Lee?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
dev);
> +
> + return ret;
> +}
> +
> +static void ti_sn_pwm_get_state(struct pwm_chip *chip, struct pwm_device
> *pwm,
> + struct pwm_state *state)
> +{
> + struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
> + unsigned in
> > *pwm,
> > > + struct pwm_state *state)
> > > +{
> > > + struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
> > > + unsigned int pwm_en_inv;
> > > + unsigned int pre_div;
> > > + u16 backlight;
> > > + u16 scale;
> > > + int ret;
> > > +
> > > + ret = regmap_read(pdata->regmap, SN_PWM_EN_INV_REG, &pwm_en_inv);
> > > + if (ret)
> > > + return;
> > > +
> > > + ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_SCALE_REG, &scale);
> > > + if (ret)
> > > + return;
> > > +
> > > + ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_REG, &backlight);
> > > + if (ret)
> > > + return;
> > > +
> > > + ret = regmap_read(pdata->regmap, SN_PWM_PRE_DIV_REG, &pre_div);
> > > + if (ret)
> > > + return;
> > > +
> > > + state->enabled = FIELD_GET(SN_PWM_EN_MASK, pwm_en_inv);
> > > + if (FIELD_GET(SN_PWM_INV_MASK, pwm_en_inv))
> > > + state->polarity = PWM_POLARITY_INVERSED;
> > > + else
> > > + state->polarity = PWM_POLARITY_NORMAL;
> > > +
> > > + state->period = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * pre_div * (scale +
> > > 1),
> > > + pdata->pwm_refclk_freq);
> > > + state->duty_cycle = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * pre_div *
> > > backlight,
> > > + pdata->pwm_refclk_freq);
> >
> > What happens if scale + 1 < backlight?
>
> When we write the backlight register above, we cap it at scale, so for
> the typical case that shouldn't happen.
.get_state() is called before the first .apply(), to the values to
interpret here originate from the bootloader which might write strange
settings that the linux driver would never do. So being prudent here is
IMHO a good idea.
It's a shame that .get_state() cannot return an error.
> So I guess the one case when this could happen is if we get_state()
> before pwm_apply(), when someone else has written broken values
ack.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
If registering the platform driver fails, the function must not return
without undoing the spi driver registration first.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Uwe Kleine-König
---
drivers/staging/fbtft/fbtft.h | 5 -
1 file changed, 4 insertions(+),
The two macros FBTFT_REGISTER_DRIVER and FBTFT_REGISTER_SPI_DRIVER
contain quite some duplication: Both define an spi driver and an of device
table and the differences are quite subtle.
So create two new macros and use both twice.
Signed-off-by: Uwe Kleine-König
---
drivers/staging/fbtft
If registering the platform driver fails, the function must not return
without undoing the spi driver registration first.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Link:
https://lore.kernel.org/r/20220118181338.207943-1-u.kleine-koe...@pengutronix.de
Signed-off-by: Uwe Kl
-koe...@pengutronix.de
Signed-off-by: Uwe Kleine-König
---
drivers/staging/fbtft/fbtft.h | 93 ++-
1 file changed, 36 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 55677efc0138..6a7545b5bcd2 100644
ot;)
8687999e47d4 ("pinctrl: thunderbay: comment process of building
functions a bit")
Best regards
Uwe
Uwe Kleine-König (5):
staging: fbtft: Fix error path in fbtft_driver_module_init()
staging: fbtft: Deduplicate driver registration macros
tpm: st33zp24: Make st33zp24_remove
ng 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.
Signed-off-by: Uwe Kleine-König
---
drivers/bus/moxtet.c | 4 +---
drivers/char/tpm/st33zp24/
[Dropped a few people from Cc that are not reachable (Harry Morris,
Charles-Antoine Couret, Marco Felsch)]
On Tue, Jan 25, 2022 at 09:47:59AM +, Jonathan Cameron wrote:
> On Sun, 23 Jan 2022 18:52:01 +0100
> Uwe Kleine-König wrote:
>
> > The value returned by an spi driver&#x
Hello Greg,
On Sun, Jan 23, 2022 at 06:51:58PM +0100, Uwe Kleine-König wrote:
> The two macros FBTFT_REGISTER_DRIVER and FBTFT_REGISTER_SPI_DRIVER
> contain quite some duplication: Both define an spi driver and an of device
> table and the differences are quite subtle.
>
> So
From: Marian Cichy
Add support for the LCD Controller found on i.MX21, i.MX25 and i.MX27
Note there is already a fb driver for this hardware in the tree that is
supposed to be superseded by this one.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/imx/Kconfig | 9
From: Marian Cichy
This files documents the device tree for the new imx21-lcdc DRM driver.
Signed-off-by: Marian Cichy
Signed-off-by: Uwe Kleine-König
---
.../bindings/display/imx/fsl,imx21-lcdc.yaml | 79 +++
1 file changed, 79 insertions(+)
create mode 100644
Hello,
this patchset was created mostly by Marian Cichy, who in the meantime
left Pengutronix. I still kept his name and email address as author, but
note that the email address doesn't reach Marian any more.
There is already a maintainer entry for imx DRM drivers that matches
good enough.
This
Hello Rob,
On Fri, Jan 28, 2022 at 07:04:10AM -0600, Rob Herring wrote:
> On Fri, Jan 28, 2022 at 4:59 AM Uwe Kleine-König
> wrote:
> >
> > From: Marian Cichy
> >
> > This files documents the device tree for the new imx21-lcdc DRM driver.
>
> No, bindi
-lcdc/Makefile'.
Argh, yes, I forgot to commit that one. I'll add it in the next round,
but wait a bit for more feedback (mainly by Rob). The Makefile just
contains:
obj-$(CONFIG_DRM_IMX21_LCDC) += imx21-lcdc.o
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
p->pwm);
> + pwm_init_state(pwm, &state);
This is broken. If lp->pwm is already set at function entry, pwm is
NULL.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
is unset
(and so the previously set period is used).
So either mention in the change log that this driver doesn't modify the
pwm settings in other places or preferably pick an equivalent conversion
(plus maybe an optimisation in a separate patch).
If you go the "equivalent conversion&qu
Hello,
On Thu, Nov 04, 2021 at 02:58:38PM -0300, Maíra Canal wrote:
> Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> replace it for the atomic PWM API.
>
> Signed-off-by: Maíra Canal
LGTM,
Reviewed-by: Uwe Kleine-König
Thanks
Uwe
--
Pen
t. If I had to arbitrarily make the decision one way or the
> other I'd probably land Shawn's patch but I certainly wouldn't object
> if we went Uwe's way either. :-P
For the the relevant argument for prefixes is that tools like ctags and
cscope work more reliable. Tak
RT
> select LCD_CLASS_DEVICE
> select FB_CFB_FILLRECT
I think you need something like this instead:
depends FB && HAVE_CLK && HAS_IOMEM
depends ARCH_MXC || COMPILE_TEST
Best regards
Uwe
--
Pengutronix e.K.
TNAVIV (DRM support for Vivante GPU IP cores) (DRM_ETNAVIV) [N/y/m/?]
(NEW)
in their next run of make oldconfig and need to decide if this driver is
useful for them. Also note they only see
DRM driver for Vivante GPUs.
when pressing '?'.
Best regards
Uwe
--
Pengutr
ias Burgger's review?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:
commit mode
> and use PWM_PERIOD/PWM_HIGH_WIDTH.
You forgot to add linux-pwm to the recipents.
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
__
hardware is active or not at probe time (in most cases at least).
Best regards
Uwe
[1] https://www.spinics.net/lists/linux-pwm/msg08246.html
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Tue, Jun 25, 2019 at 11:58:21AM +0200, Thierry Reding wrote:
> On Tue, Jun 25, 2019 at 09:42:20AM +0200, Uwe Kleine-König wrote:
> > On Wed, May 22, 2019 at 06:34:28PM +0200, Paul Cercueil wrote:
> > > When the driver probes, the PWM pin is automatically configured to its
&
xplicitly handle pinctrl stuff
You presume that b) being commonly done is a sign of "our device trees
and kernel subsystems still maturing". But maybe it's only that the
capabilities provided by pinctrl subsystem without extra effort is good
enough?
Best regards
Uwe
--
Pengutronix
On Wed, Jun 26, 2019 at 11:58:44AM +0200, Thierry Reding wrote:
> On Wed, Jun 26, 2019 at 10:58:27AM +0200, Uwe Kleine-König wrote:
> > On Tue, Jun 25, 2019 at 11:38:39AM +0200, Thierry Reding wrote:
> > > On Mon, Jun 24, 2019 at 12:28:44PM +0100, Daniel Thompson wrote:
>
/arch/arm/configs/imx_v6_v7_defconfig
> @@ -397,10 +397,11 @@ CONFIG_SENSORS_ISL29018=y
> CONFIG_MAG3110=y
> CONFIG_MPL3115=y
> CONFIG_PWM=y
> CONFIG_PWM_FSL_FTM=y
> CONFIG_PWM_IMX=y
> +CONFIG_PWM_IMX27=y
PWM_IMX is gone, so this can be dropped (but see my patch reference
On Fri, Mar 22, 2019 at 10:47:00AM +0100, Thierry Reding wrote:
> On Thu, Mar 21, 2019 at 10:49:03AM +0100, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Wed, Mar 20, 2019 at 01:01:26PM +, Leonard Crestez wrote:
> > > Commit d80f8206905c ("pwm: imx: Split
$Subject ~= s/bindngs/bindings/
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel
Hello,
On Thu, May 26, 2022 at 10:25:38PM +0200, Uwe Kleine-König wrote:
> 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.
I intend to change the prototype of i2c remove callbacks to return void
aft
Applied to drm-misc-next.
just a quick note that there is an easy conflict between this patch and
my effort to make i2c remove callbacks return void. I intend to post my
series on top of v5.20-rc1, so if this patch goes in before, everything
is fine.
See
https://lore.kernel.org/linux-i2c/202206
k/20220620171815.114212-1-u.kleine-koe...@pengutronix.de
(Pro tipp: The commit in next has a Link: footer. If you follow the
link, you find the thread that was actually applied (i.e. v9) and where
the fix is also contained.)
@Stephen: It would be a great favour to our testers if you could apply
the fix ...
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
lent kcalloc().
>
> Signed-off-by: Christophe JAILLET
LGTM
Acked-by: Christophe JAILLET
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
On Mon, Feb 07, 2022 at 09:31:00AM +, Lee Jones wrote:
> On Mon, 07 Feb 2022, Uwe Kleine-König wrote:
>
> > On Sat, Feb 05, 2022 at 08:40:48AM +0100, Christophe JAILLET wrote:
> > > kmalloc_array()/kcalloc() should be used to avoid potential overflow when
> > >
e and so MODULE_DEVICE_TABLE
evaluates to nothing. Will send a patch for that one.
Best regards
Uwe
[1] git grep -E '^[[:space:]]*MODULE_DEVICE_TABLE\([^;]*$'
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Hello Ian,
On Wed, Apr 20, 2022 at 09:57:27AM -0400, Ian Cowan wrote:
> On Wed, Apr 20, 2022 at 08:47:11AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 19, 2022 at 03:21:28PM -0400, Ian Cowan wrote:
> > > Removed an unnecessary semicolon at the end of a macro call
> >
: Uwe Kleine-König
---
drivers/gpu/drm/solomon/ssd130x-i2c.c | 4 +++-
drivers/gpu/drm/solomon/ssd130x.c | 4 +---
drivers/gpu/drm/solomon/ssd130x.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c
b/drivers/gpu/drm/solomon/ss
.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/ti-tfp410.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index ba3fa2a9b8a4..756b3e6e776b 100644
--- a/drivers/gpu/drm/bridge/ti
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
---
drivers/gpu/drm/i2c/sil164_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i2c
dapt for dropped and new drivers.
The patches are also available at
https://git.pengutronix.de/git/ukl/linux i2c-remove-void
Thanks
Uwe
Uwe Kleine-König (6):
drm/i2c/sil164: Drop no-op remove function
leds: lm3697: Remove duplicated error reporting in .remove()
leds: lm3601x: Don't use
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
---
drivers/gpu/drm/i2c/sil164_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i2c
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
Forwarded: id:20220526202538.1723142-1-u.kleine-koe...@pengutronix.de
---
drivers/gpu/drm/i2c/sil164_drv.c | 7 ---
1
; Either way:
>
> Reviewed-by: Jeremy Kerr
Added to my tree, too.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[Dropped most people from Cc, keeping only lists]
On Wed, Jun 29, 2022 at 04:11:26PM +0300, Andrey Ryabinin wrote:
> On 6/28/22 17:03, Uwe Kleine-König wrote:
> > From: Uwe Kleine-König
> >
> > The value returned by an i2c driver's remove function is mostly ignored.
>
On Tue, Jul 05, 2022 at 12:08:52PM +0200, Jean Delvare wrote:
> On Tue, 28 Jun 2022 16:03:12 +0200, Uwe Kleine-König wrote:
> > From: Uwe Kleine-König
> >
> > The value returned by an i2c driver's remove function is mostly ignored.
> > (Only an error message is
On Wed, Jul 06, 2022 at 12:13:15PM +0300, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 04:03:12PM +0200, Uwe Kleine-König wrote:
> > From: Uwe Kleine-König
> >
> > The value returned by an i2c driver's remove function is mostly ignored.
> > (Only an error me
accordingly.
There is no intended change of behaviour.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/chipone-icn6211.c | 4 +---
drivers/gpu/drm/bridge/tc358762.c| 4 +---
drivers/gpu/drm/bridge/tc358764.c| 4 +---
drivers
panel_simple_remove() returns zero unconditionally. Make it return no value
instead making more obvious what happens in the callers.
This is a preparation for making platform and mipi-dsi remove callbacks
return void.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/panel/panel-simple.c
river
core remove functions return void.
Best regards
Uwe
Uwe Kleine-König (3):
drm/panel: simple: Make panel_simple_remove() return void
drm/panel-novatek-nt35510: Emit an error message if power off fails
drm/mipi-dsi: Make remove callback return void
drivers/gpu/drm/bridge/chipone-icn6
Returning an error code from a mipi_dsi remove callback fails, this is
silently ignored. (mipi_dsi_drv_remove() propagates the return value to
device_remove() which ignores it.) So emit an error code in the driver
remove function and return 0.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm
Hello Sam,
On Sat, Jul 09, 2022 at 10:50:55AM +0200, Sam Ravnborg wrote:
> On Fri, Jul 08, 2022 at 11:49:22AM +0200, Uwe Kleine-König wrote:
> > All implementations return 0 and the return value of mipi_dsi_drv_remove()
> > is ignored anyhow.
> >
> > So change
r
the individual drivers.
Signed-off-by: Uwe Kleine-König
---
Changes since v1
(20210514100142.1182997-1-u.kleine-koe...@pengutronix.de) from
2021-05-14:
- rebased to next-20220909
was something around v5.13-rc2 before, required to fix context
changes in the nouveau Kconfig file. git
This suppresses diagnosis for PWM_DEBUG routines and makes sure that
pwm->state isn't modified in pwm_device_request() if .get_state() fails.
Signed-off-by: Uwe Kleine-König
---
drivers/pwm/core.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/dri
Record and report an error code for the events. This allows to report
about failed calls without ambiguity and so gives a more complete
picture.
Signed-off-by: Uwe Kleine-König
---
drivers/pwm/core.c | 18 --
include/trace/events/pwm.h | 20 ++--
2 files
1 - 100 of 837 matches
Mail list logo
