From: Miquel RAYNAL <miquel.raynal@free-electrons.com>
To: Baruch Siach <baruch@tkos.co.il>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
Zhang Rui <rui.zhang@intel.com>,
Eduardo Valentin <edubezval@gmail.com>,
devicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
Andrew Lunn <andrew@lunn.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Russell King <linux@armlinux.org.uk>,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/4] thermal: armada: add support for CP110
Date: Wed, 13 Dec 2017 09:55:01 +0100 [thread overview]
Message-ID: <20171213095501.1988749d@xps13> (raw)
In-Reply-To: <20171213083848.j5het742yavxvkkw@sapphire.tkos.co.il>
Hello Baruch,
> > > How would a separate init_sensor routine improve things?
> >
> > So yes please do it, thanks to this you won't have to add the
> > control_msb_offset member and can use a clean function. Moreover if
> > in the future we see some usefulness for this LSB register then we
> > could use the new compatible for the Armada 38x.
>
> There are two separate issues here:
>
> 1. DT binding
>
> 2. init_sensor callback implementation
>
> We both agree on #1. The A38x and CP110 need separate compatible
> strings. In case we want to access the LSB control register on Armada
> 38x, we will need yet another compatible string
> (marvell,armada380-v2-thermal maybe?).
>
> As for #2, I'm all for sharing as much code as possible. I find the
> vendor kernel approach of duplicating the init routines[1] unhelpful
> as it violates the DRY principle. The differences between
> armada380_init_sensor() and cp110_init_sensor() are minor. In my
> opinion, these differences should be expressed explicitly in the
> armada_thermal_data, in a similar way to my suggested
> control_msb_offset field. The vendor code hides these differences in
> slight variations of duplicated code.
>
> What is the advantage of a separate init routine?
The advantage is that is the very near future I plan to add the
overheat interrupt only on CP110 (not on 38x) and this needs some
initialization. So if we don't make different routines now, I will
have to do it right after.
What would be fine is to have the shared code in a separate function,
like it is done in Marvell kernel. What do you think about that?
Thanks,
Miquèl
WARNING: multiple messages have this Message-ID (diff)
From: miquel.raynal@free-electrons.com (Miquel RAYNAL)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/4] thermal: armada: add support for CP110
Date: Wed, 13 Dec 2017 09:55:01 +0100 [thread overview]
Message-ID: <20171213095501.1988749d@xps13> (raw)
In-Reply-To: <20171213083848.j5het742yavxvkkw@sapphire.tkos.co.il>
Hello Baruch,
> > > How would a separate init_sensor routine improve things?
> >
> > So yes please do it, thanks to this you won't have to add the
> > control_msb_offset member and can use a clean function. Moreover if
> > in the future we see some usefulness for this LSB register then we
> > could use the new compatible for the Armada 38x.
>
> There are two separate issues here:
>
> 1. DT binding
>
> 2. init_sensor callback implementation
>
> We both agree on #1. The A38x and CP110 need separate compatible
> strings. In case we want to access the LSB control register on Armada
> 38x, we will need yet another compatible string
> (marvell,armada380-v2-thermal maybe?).
>
> As for #2, I'm all for sharing as much code as possible. I find the
> vendor kernel approach of duplicating the init routines[1] unhelpful
> as it violates the DRY principle. The differences between
> armada380_init_sensor() and cp110_init_sensor() are minor. In my
> opinion, these differences should be expressed explicitly in the
> armada_thermal_data, in a similar way to my suggested
> control_msb_offset field. The vendor code hides these differences in
> slight variations of duplicated code.
>
> What is the advantage of a separate init routine?
The advantage is that is the very near future I plan to add the
overheat interrupt only on CP110 (not on 38x) and this needs some
initialization. So if we don't make different routines now, I will
have to do it right after.
What would be fine is to have the shared code in a separate function,
like it is done in Marvell kernel. What do you think about that?
Thanks,
Miqu?l
next prev parent reply other threads:[~2017-12-13 8:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-03 11:11 [PATCH v2 1/4] dt-bindings: thermal/armada: describe AP806 and CP110 Baruch Siach
2017-12-03 11:11 ` Baruch Siach
2017-12-03 11:11 ` [PATCH v2 2/4] thermal: armada: add support for AP806 Baruch Siach
2017-12-03 11:11 ` Baruch Siach
[not found] ` <f8c589337a4fb78852eadf15058e8f8d132d4dc0.1512299484.git.baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
2017-12-03 11:11 ` [PATCH v2 3/4] thermal: armada: add support for CP110 Baruch Siach
2017-12-03 11:11 ` Baruch Siach
2017-12-11 15:09 ` Miquel RAYNAL
2017-12-11 15:09 ` Miquel RAYNAL
2017-12-11 15:27 ` Baruch Siach
2017-12-11 15:27 ` Baruch Siach
2017-12-11 17:02 ` Gregory CLEMENT
2017-12-11 17:02 ` Gregory CLEMENT
[not found] ` <87y3m9qjt2.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-12-13 8:38 ` Baruch Siach
2017-12-13 8:38 ` Baruch Siach
2017-12-13 8:55 ` Miquel RAYNAL [this message]
2017-12-13 8:55 ` Miquel RAYNAL
2017-12-13 9:10 ` Baruch Siach
2017-12-13 9:10 ` Baruch Siach
[not found] ` <20171213091040.jwsphlax4yidm4qp-MwjkAAnuF3khR1HGirfZ1z4kX+cae0hd@public.gmane.org>
2017-12-13 9:21 ` Gregory CLEMENT
2017-12-13 9:21 ` Gregory CLEMENT
2017-12-13 9:13 ` Gregory CLEMENT
2017-12-13 9:13 ` Gregory CLEMENT
[not found] ` <874lovq9cx.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-12-13 9:42 ` Baruch Siach
2017-12-13 9:42 ` Baruch Siach
2017-12-03 11:11 ` [PATCH v2 4/4] thermal: armada: use msleep for long delays Baruch Siach
2017-12-03 11:11 ` Baruch Siach
2017-12-04 22:33 ` [PATCH v2 1/4] dt-bindings: thermal/armada: describe AP806 and CP110 Rob Herring
2017-12-04 22:33 ` Rob Herring
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=20171213095501.1988749d@xps13 \
--to=miquel.raynal@free-electrons.com \
--cc=andrew@lunn.ch \
--cc=baruch@tkos.co.il \
--cc=devicetree@vger.kernel.org \
--cc=edubezval@gmail.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=rui.zhang@intel.com \
--cc=sebastian.hesselbarth@gmail.com \
/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.