From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 08/15] backlight: pwm_bl: remove useless call to pwm_set_period
Date: Mon, 20 Jul 2015 10:36:50 +0200 [thread overview]
Message-ID: <20150720083648.GK29614@ulmo> (raw)
In-Reply-To: <20150720102143.05949ca2@bbrezillon>
On Mon, Jul 20, 2015 at 10:21:43AM +0200, Boris Brezillon wrote:
> On Mon, 20 Jul 2015 10:16:00 +0200
> Thierry Reding <thierry.reding@gmail.com> wrote:
>
> > On Wed, Jul 01, 2015 at 10:21:54AM +0200, Boris Brezillon wrote:
> > > The PWM period will be set when calling pwm_config. Remove this useless
> > > call to pwm_set_period, which might mess up with the initial PWM state
> > > once we have added proper support for PWM init state retrieval.
> > >
> > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > ---
> > > drivers/video/backlight/pwm_bl.c | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > index ae498c1..fe5597c 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> > > @@ -295,10 +295,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> > > * via the PWM lookup table.
> > > */
> > > pb->period = pwm_get_default_period(pb->pwm);
> > > - if (!pb->period && (data->pwm_period_ns > 0)) {
> > > + if (!pb->period && (data->pwm_period_ns > 0))
> > > pb->period = data->pwm_period_ns;
> > > - pwm_set_period(pb->pwm, data->pwm_period_ns);
> > > - }
> > >
> > > pb->lth_brightness = data->lth_brightness * (pb->period / pb->scale);
> >
> > As far as I remember this line is there in order to pass in a period if
> > the backlight driver is initialized from board setup files. In such a
> > case there won't be an period associated with the PWM channel in the
> > first place.
> >
> > I think even with the introduction of a default period, we'd be missing
> > out on the board setup case because there is no standard place where it
> > is being set, so it must come from the platform data.
>
> AFAICT, we don't need to explicitly set the period when probing the
> backlight device, because it will be set next time we call
> pwm_config(), and since we're passing pb->period when calling
> pwm_config() everything should be fine.
Calling pwm_set_period() is still good for consistency. Consider for
example what happens if after the driver were to call pwm_get_period().
It would return some more or less random value (likely 0 or whatever it
had been set to by an earlier user).
Technically I think the most proper equivalent here would be to set the
default state's period to data->pwm_period_ns, but I don't think that's
proper to do. Perhaps since this is only relevant to boards where the
backlight device is created from board setup code we don't have to care
so much about messing up the initial state because either the board
setup code has been carefully written to match what the bootloader set
up, or because they don't match at all, in which case we don't have to
worry anyway.
Of course the right thing to do would be to replace all initialization
of the data->pwm_period_ns by proper PWM lookup tables, but that's
proven difficult in the past since very few people still have access to
hardware where that code gets executed.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150720/fa5731d1/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Boris Brezillon
<boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Bryan Wu <cooloney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Richard Purdie <rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org>,
Jacek Anaszewski
<j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jean-Christophe Plagniol-Villard
<plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>,
Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Alexandre Courbot
<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
Jingoo Han <jingoohan1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Doug Anderson <dianders-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Subject: Re: [RFC PATCH 08/15] backlight: pwm_bl: remove useless call to pwm_set_period
Date: Mon, 20 Jul 2015 10:36:50 +0200 [thread overview]
Message-ID: <20150720083648.GK29614@ulmo> (raw)
In-Reply-To: <20150720102143.05949ca2@bbrezillon>
[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]
On Mon, Jul 20, 2015 at 10:21:43AM +0200, Boris Brezillon wrote:
> On Mon, 20 Jul 2015 10:16:00 +0200
> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > On Wed, Jul 01, 2015 at 10:21:54AM +0200, Boris Brezillon wrote:
> > > The PWM period will be set when calling pwm_config. Remove this useless
> > > call to pwm_set_period, which might mess up with the initial PWM state
> > > once we have added proper support for PWM init state retrieval.
> > >
> > > Signed-off-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > > ---
> > > drivers/video/backlight/pwm_bl.c | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > index ae498c1..fe5597c 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> > > @@ -295,10 +295,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> > > * via the PWM lookup table.
> > > */
> > > pb->period = pwm_get_default_period(pb->pwm);
> > > - if (!pb->period && (data->pwm_period_ns > 0)) {
> > > + if (!pb->period && (data->pwm_period_ns > 0))
> > > pb->period = data->pwm_period_ns;
> > > - pwm_set_period(pb->pwm, data->pwm_period_ns);
> > > - }
> > >
> > > pb->lth_brightness = data->lth_brightness * (pb->period / pb->scale);
> >
> > As far as I remember this line is there in order to pass in a period if
> > the backlight driver is initialized from board setup files. In such a
> > case there won't be an period associated with the PWM channel in the
> > first place.
> >
> > I think even with the introduction of a default period, we'd be missing
> > out on the board setup case because there is no standard place where it
> > is being set, so it must come from the platform data.
>
> AFAICT, we don't need to explicitly set the period when probing the
> backlight device, because it will be set next time we call
> pwm_config(), and since we're passing pb->period when calling
> pwm_config() everything should be fine.
Calling pwm_set_period() is still good for consistency. Consider for
example what happens if after the driver were to call pwm_get_period().
It would return some more or less random value (likely 0 or whatever it
had been set to by an earlier user).
Technically I think the most proper equivalent here would be to set the
default state's period to data->pwm_period_ns, but I don't think that's
proper to do. Perhaps since this is only relevant to boards where the
backlight device is created from board setup code we don't have to care
so much about messing up the initial state because either the board
setup code has been carefully written to match what the bootloader set
up, or because they don't match at all, in which case we don't have to
worry anyway.
Of course the right thing to do would be to replace all initialization
of the data->pwm_period_ns by proper PWM lookup tables, but that's
proven difficult in the past since very few people still have access to
hardware where that code gets executed.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 08/15] backlight: pwm_bl: remove useless call to pwm_set_period
Date: Mon, 20 Jul 2015 08:36:50 +0000 [thread overview]
Message-ID: <20150720083648.GK29614@ulmo> (raw)
In-Reply-To: <20150720102143.05949ca2@bbrezillon>
[-- Attachment #1: Type: text/plain, Size: 3145 bytes --]
On Mon, Jul 20, 2015 at 10:21:43AM +0200, Boris Brezillon wrote:
> On Mon, 20 Jul 2015 10:16:00 +0200
> Thierry Reding <thierry.reding@gmail.com> wrote:
>
> > On Wed, Jul 01, 2015 at 10:21:54AM +0200, Boris Brezillon wrote:
> > > The PWM period will be set when calling pwm_config. Remove this useless
> > > call to pwm_set_period, which might mess up with the initial PWM state
> > > once we have added proper support for PWM init state retrieval.
> > >
> > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > ---
> > > drivers/video/backlight/pwm_bl.c | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > index ae498c1..fe5597c 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> > > @@ -295,10 +295,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> > > * via the PWM lookup table.
> > > */
> > > pb->period = pwm_get_default_period(pb->pwm);
> > > - if (!pb->period && (data->pwm_period_ns > 0)) {
> > > + if (!pb->period && (data->pwm_period_ns > 0))
> > > pb->period = data->pwm_period_ns;
> > > - pwm_set_period(pb->pwm, data->pwm_period_ns);
> > > - }
> > >
> > > pb->lth_brightness = data->lth_brightness * (pb->period / pb->scale);
> >
> > As far as I remember this line is there in order to pass in a period if
> > the backlight driver is initialized from board setup files. In such a
> > case there won't be an period associated with the PWM channel in the
> > first place.
> >
> > I think even with the introduction of a default period, we'd be missing
> > out on the board setup case because there is no standard place where it
> > is being set, so it must come from the platform data.
>
> AFAICT, we don't need to explicitly set the period when probing the
> backlight device, because it will be set next time we call
> pwm_config(), and since we're passing pb->period when calling
> pwm_config() everything should be fine.
Calling pwm_set_period() is still good for consistency. Consider for
example what happens if after the driver were to call pwm_get_period().
It would return some more or less random value (likely 0 or whatever it
had been set to by an earlier user).
Technically I think the most proper equivalent here would be to set the
default state's period to data->pwm_period_ns, but I don't think that's
proper to do. Perhaps since this is only relevant to boards where the
backlight device is created from board setup code we don't have to care
so much about messing up the initial state because either the board
setup code has been carefully written to match what the bootloader set
up, or because they don't match at all, in which case we don't have to
worry anyway.
Of course the right thing to do would be to replace all initialization
of the data->pwm_period_ns by proper PWM lookup tables, but that's
proven difficult in the past since very few people still have access to
hardware where that code gets executed.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-07-20 8:36 UTC|newest]
Thread overview: 204+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-01 8:21 [RFC PATCH 00/15] pwm: add support for atomic update Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` [RFC PATCH 01/15] pwm: add the pwm_is_enabled() helper Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-20 7:47 ` Thierry Reding
2015-07-20 7:47 ` Thierry Reding
2015-07-20 7:47 ` Thierry Reding
2015-07-01 8:21 ` [RFC PATCH 02/15] pwm: fix pwm_get_period and pwm_get_duty_cycle prototypes Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-20 7:50 ` Thierry Reding
2015-07-20 7:50 ` Thierry Reding
2015-07-20 7:50 ` Thierry Reding
2015-07-01 8:21 ` [RFC PATCH 03/15] pwm: add pwm_get_polarity helper function Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-20 7:52 ` Thierry Reding
2015-07-20 7:52 ` Thierry Reding
2015-07-20 7:52 ` Thierry Reding
2015-07-01 8:21 ` [RFC PATCH 04/15] pwm: make use of pwm_get_xxx helpers where appropriate Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-20 8:00 ` Thierry Reding
2015-07-20 8:00 ` Thierry Reding
2015-07-20 8:00 ` Thierry Reding
2015-07-01 8:21 ` [RFC PATCH 05/15] pwm: introduce default period and polarity concepts Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-02 6:44 ` Uwe Kleine-König
2015-07-02 6:44 ` Uwe Kleine-König
2015-07-02 6:44 ` Uwe Kleine-König
2015-07-02 7:49 ` Boris Brezillon
2015-07-02 7:49 ` Boris Brezillon
2015-07-02 7:49 ` Boris Brezillon
2015-07-20 8:03 ` Thierry Reding
2015-07-20 8:03 ` Thierry Reding
2015-07-20 8:03 ` Thierry Reding
2015-07-20 8:14 ` Boris Brezillon
2015-07-20 8:14 ` Boris Brezillon
2015-07-20 8:14 ` Boris Brezillon
2015-07-20 8:22 ` Thierry Reding
2015-07-20 8:22 ` Thierry Reding
2015-07-20 8:22 ` Thierry Reding
2015-07-20 8:32 ` Boris Brezillon
2015-07-20 8:32 ` Boris Brezillon
2015-07-20 8:32 ` Boris Brezillon
2015-07-01 8:21 ` [RFC PATCH 06/15] pwm: define a new pwm_state struct Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-20 8:04 ` Thierry Reding
2015-07-20 8:04 ` Thierry Reding
2015-07-20 8:04 ` Thierry Reding
2015-07-20 10:01 ` Boris Brezillon
2015-07-20 10:01 ` Boris Brezillon
2015-07-20 10:01 ` Boris Brezillon
2015-07-20 10:09 ` Thierry Reding
2015-07-20 10:09 ` Thierry Reding
2015-07-20 10:09 ` Thierry Reding
2015-07-20 10:12 ` Boris Brezillon
2015-07-20 10:12 ` Boris Brezillon
2015-07-20 10:12 ` Boris Brezillon
2015-07-01 8:21 ` [RFC PATCH 07/15] pwm: move the enabled/disabled info to " Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-20 8:11 ` Thierry Reding
2015-07-20 8:11 ` Thierry Reding
2015-07-20 8:11 ` Thierry Reding
2015-07-01 8:21 ` [RFC PATCH 08/15] backlight: pwm_bl: remove useless call to pwm_set_period Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-20 8:16 ` Thierry Reding
2015-07-20 8:16 ` Thierry Reding
2015-07-20 8:16 ` Thierry Reding
2015-07-20 8:21 ` Boris Brezillon
2015-07-20 8:21 ` Boris Brezillon
2015-07-20 8:21 ` Boris Brezillon
2015-07-20 8:36 ` Thierry Reding [this message]
2015-07-20 8:36 ` Thierry Reding
2015-07-20 8:36 ` Thierry Reding
2015-07-20 8:50 ` Boris Brezillon
2015-07-20 8:50 ` Boris Brezillon
2015-07-20 8:50 ` Boris Brezillon
2015-07-20 9:10 ` Thierry Reding
2015-07-20 9:10 ` Thierry Reding
2015-07-20 9:10 ` Thierry Reding
2015-07-20 9:57 ` Boris Brezillon
2015-07-20 9:57 ` Boris Brezillon
2015-07-20 9:57 ` Boris Brezillon
2015-07-20 10:01 ` Thierry Reding
2015-07-20 10:01 ` Thierry Reding
2015-07-20 10:01 ` Thierry Reding
2015-07-01 8:21 ` [RFC PATCH 09/15] pwm: declare a default PWM state Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` [RFC PATCH 10/15] pwm: add the PWM initial state retrieval infra Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-20 9:01 ` Thierry Reding
2015-07-20 9:01 ` Thierry Reding
2015-07-20 9:01 ` Thierry Reding
2015-07-20 9:42 ` Boris Brezillon
2015-07-20 9:42 ` Boris Brezillon
2015-07-20 9:42 ` Boris Brezillon
2015-07-01 8:21 ` [RFC PATCH 11/15] pwm: add the core infrastructure to allow atomic update Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-20 8:59 ` Thierry Reding
2015-07-20 8:59 ` Thierry Reding
2015-07-20 8:59 ` Thierry Reding
2015-07-20 9:48 ` Boris Brezillon
2015-07-20 9:48 ` Boris Brezillon
2015-07-20 9:48 ` Boris Brezillon
2015-07-20 10:04 ` Thierry Reding
2015-07-20 10:04 ` Thierry Reding
2015-07-20 10:04 ` Thierry Reding
2015-07-01 8:21 ` [RFC PATCH 12/15] pwm: rockchip: add initial state retrieval Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 21:44 ` Heiko Stübner
2015-07-01 21:44 ` Heiko Stübner
2015-07-01 21:44 ` Heiko Stübner
2015-07-02 7:46 ` Boris Brezillon
2015-07-02 7:46 ` Boris Brezillon
2015-07-02 7:46 ` Boris Brezillon
2015-07-01 8:21 ` [RFC PATCH 13/15] pwm: rockchip: add support for atomic update Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 8:21 ` Boris Brezillon
2015-07-01 21:48 ` Heiko Stübner
2015-07-01 21:48 ` Heiko Stübner
2015-07-01 21:48 ` Heiko Stübner
2015-07-02 7:43 ` Boris Brezillon
2015-07-02 7:43 ` Boris Brezillon
2015-07-02 7:43 ` Boris Brezillon
2015-07-01 8:22 ` [RFC PATCH 14/15] regulator: pwm: implement ->enable(), ->disable() and ->is_enabled methods Boris Brezillon
2015-07-01 8:22 ` Boris Brezillon
2015-07-01 8:22 ` Boris Brezillon
2015-07-01 11:58 ` Heiko Stübner
2015-07-01 11:58 ` Heiko Stübner
2015-07-01 11:58 ` Heiko Stübner
2015-07-01 12:05 ` Boris Brezillon
2015-07-01 12:05 ` Boris Brezillon
2015-07-01 12:05 ` Boris Brezillon
2015-07-01 12:08 ` Heiko Stübner
2015-07-01 12:08 ` Heiko Stübner
2015-07-01 12:08 ` Heiko Stübner
2015-07-01 12:19 ` Boris Brezillon
2015-07-01 12:19 ` Boris Brezillon
2015-07-01 12:19 ` Boris Brezillon
2015-07-14 10:50 ` Mark Brown
2015-07-14 10:50 ` Mark Brown
2015-07-14 10:50 ` Mark Brown
2015-07-14 11:02 ` Boris Brezillon
2015-07-14 11:02 ` Boris Brezillon
2015-07-14 11:02 ` Boris Brezillon
2015-07-14 11:08 ` Mark Brown
2015-07-14 11:08 ` Mark Brown
2015-07-14 11:08 ` Mark Brown
2015-07-14 11:16 ` Boris Brezillon
2015-07-14 11:16 ` Boris Brezillon
2015-07-14 11:16 ` Boris Brezillon
2015-07-01 8:22 ` [RFC PATCH 15/15] regulator: pwm: properly initialize the ->state field Boris Brezillon
2015-07-01 8:22 ` Boris Brezillon
2015-07-01 8:22 ` Boris Brezillon
2015-07-14 10:51 ` Mark Brown
2015-07-14 10:51 ` Mark Brown
2015-07-14 10:51 ` Mark Brown
2015-07-14 11:03 ` Boris Brezillon
2015-07-14 11:03 ` Boris Brezillon
2015-07-14 11:03 ` Boris Brezillon
2015-07-01 21:50 ` [RFC PATCH 16/15] pwm: add informations about polarity, duty cycle and period to debugfs Heiko Stübner
2015-07-01 21:50 ` Heiko Stübner
2015-07-01 21:50 ` Heiko Stübner
2015-07-02 13:01 ` Boris Brezillon
2015-07-02 13:01 ` Boris Brezillon
2015-07-02 13:01 ` Boris Brezillon
2015-07-03 8:43 ` [PATCH] " Heiko Stübner
2015-07-03 8:43 ` Heiko Stübner
2015-07-03 8:43 ` Heiko Stübner
2015-07-01 21:57 ` [RFC PATCH 00/15] pwm: add support for atomic update Heiko Stübner
2015-07-01 21:57 ` Heiko Stübner
2015-07-01 21:57 ` Heiko Stübner
2015-07-02 7:55 ` Boris Brezillon
2015-07-02 7:55 ` Boris Brezillon
2015-07-02 7:55 ` Boris Brezillon
2015-07-02 7:03 ` Uwe Kleine-König
2015-07-02 7:03 ` Uwe Kleine-König
2015-07-02 7:03 ` Uwe Kleine-König
2015-07-02 7:17 ` Tomi Valkeinen
2015-07-02 7:17 ` Tomi Valkeinen
2015-07-02 7:17 ` Tomi Valkeinen
2015-07-02 7:42 ` Uwe Kleine-König
2015-07-02 7:42 ` Uwe Kleine-König
2015-07-02 7:42 ` Uwe Kleine-König
2015-07-02 7:30 ` Boris Brezillon
2015-07-02 7:30 ` Boris Brezillon
2015-07-02 7:30 ` Boris Brezillon
2015-07-20 7:16 ` Boris Brezillon
2015-07-20 7:16 ` Boris Brezillon
2015-07-20 7:16 ` Boris Brezillon
2015-07-20 7:43 ` Thierry Reding
2015-07-20 7:43 ` Thierry Reding
2015-07-20 7:43 ` Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150720083648.GK29614@ulmo \
--to=thierry.reding@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.