All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: Ran Bi <ran.bi@mediatek.com>,
	Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>,
	Rob Herring <robh+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Sean Wang <sean.wang@mediatek.com>,
	Sebastian Reichel <sre@kernel.org>,
	Eddie Huang <eddie.huang@mediatek.com>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Frank Wunderlich <frank-w@public-files.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Richard Fontana <rfontana@redhat.com>,
	Josef Friedl <josef.friedl@speed.at>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-rtc@vger.kernel.org,
	Nicolas Boichat <drinkcat@chromium.org>,
	srv_heupstream@mediatek.com
Subject: Re: [PATCH v10 4/5] rtc: mt6397: Add support for the MediaTek MT6358 RTC
Date: Fri, 13 Mar 2020 08:47:34 +0100	[thread overview]
Message-ID: <20200313074734.GD3384@piout.net> (raw)
In-Reply-To: <20200313072230.GC3142@dell>

On 13/03/2020 07:22:30+0000, Lee Jones wrote:
> > > >  struct mt6397_rtc {
> > > >  	struct device           *dev;
> > > >  	struct rtc_device       *rtc_dev;
> > > > @@ -74,6 +80,7 @@ struct mt6397_rtc {
> > > >  	struct regmap           *regmap;
> > > >  	int                     irq;
> > > >  	u32                     addr_base;
> > > > +	const struct mtk_rtc_data *data;
> > > 
> > > 'data' is a terrible variable name.
> > > 
> > > Why do you need to store this?
> > > 
> > > It's one variable which is used once AFAICT.
> > 
> > I would rename 'data' to 'config'.
> > 
> > This struct will be extended in future patches to achieve more PMIC chip
> > compatibility.
> 
> On closer inspection, it looks like wrtgr (also not a great name for a
> variable by the way) is a register address.  Is that correct?
> Initially I thought it was a model number, which would have been a
> suitable candidate for entry into OF .data.
> 
> However, describing register addresses in OF .data does not sound like
> good practice.  It is usually used to identify a platform in the cases
> where platforms cannot be otherwise dynamically interrogated for model
> number via a register read.
> 
> Describing register maps via 'config' data is a slippery slope.

I'm not sure I get what you mean, there are dozens if not hundreds of
drivers doing it exactly that way. What is the difference between having
.data pointing to a register map and having .data containing a model
number and then use that model number to get the register map?

of_device_id::data definitively isn't config data as the DT describes
the hardware, not the configuration.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Josef Friedl <josef.friedl@speed.at>,
	Nicolas Boichat <drinkcat@chromium.org>,
	srv_heupstream@mediatek.com,
	Frank Wunderlich <frank-w@public-files.de>,
	Ran Bi <ran.bi@mediatek.com>, Sean Wang <sean.wang@mediatek.com>,
	Sebastian Reichel <sre@kernel.org>,
	linux-kernel@vger.kernel.org,
	Richard Fontana <rfontana@redhat.com>,
	devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Eddie Huang <eddie.huang@mediatek.com>,
	Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>,
	linux-rtc@vger.kernel.org
Subject: Re: [PATCH v10 4/5] rtc: mt6397: Add support for the MediaTek MT6358 RTC
Date: Fri, 13 Mar 2020 08:47:34 +0100	[thread overview]
Message-ID: <20200313074734.GD3384@piout.net> (raw)
In-Reply-To: <20200313072230.GC3142@dell>

On 13/03/2020 07:22:30+0000, Lee Jones wrote:
> > > >  struct mt6397_rtc {
> > > >  	struct device           *dev;
> > > >  	struct rtc_device       *rtc_dev;
> > > > @@ -74,6 +80,7 @@ struct mt6397_rtc {
> > > >  	struct regmap           *regmap;
> > > >  	int                     irq;
> > > >  	u32                     addr_base;
> > > > +	const struct mtk_rtc_data *data;
> > > 
> > > 'data' is a terrible variable name.
> > > 
> > > Why do you need to store this?
> > > 
> > > It's one variable which is used once AFAICT.
> > 
> > I would rename 'data' to 'config'.
> > 
> > This struct will be extended in future patches to achieve more PMIC chip
> > compatibility.
> 
> On closer inspection, it looks like wrtgr (also not a great name for a
> variable by the way) is a register address.  Is that correct?
> Initially I thought it was a model number, which would have been a
> suitable candidate for entry into OF .data.
> 
> However, describing register addresses in OF .data does not sound like
> good practice.  It is usually used to identify a platform in the cases
> where platforms cannot be otherwise dynamically interrogated for model
> number via a register read.
> 
> Describing register maps via 'config' data is a slippery slope.

I'm not sure I get what you mean, there are dozens if not hundreds of
drivers doing it exactly that way. What is the difference between having
.data pointing to a register map and having .data containing a model
number and then use that model number to get the register map?

of_device_id::data definitively isn't config data as the DT describes
the hardware, not the configuration.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Josef Friedl <josef.friedl@speed.at>,
	Nicolas Boichat <drinkcat@chromium.org>,
	srv_heupstream@mediatek.com,
	Frank Wunderlich <frank-w@public-files.de>,
	Ran Bi <ran.bi@mediatek.com>, Sean Wang <sean.wang@mediatek.com>,
	Sebastian Reichel <sre@kernel.org>,
	linux-kernel@vger.kernel.org,
	Richard Fontana <rfontana@redhat.com>,
	devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Eddie Huang <eddie.huang@mediatek.com>,
	Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>,
	linux-rtc@vger.kernel.org
Subject: Re: [PATCH v10 4/5] rtc: mt6397: Add support for the MediaTek MT6358 RTC
Date: Fri, 13 Mar 2020 08:47:34 +0100	[thread overview]
Message-ID: <20200313074734.GD3384@piout.net> (raw)
In-Reply-To: <20200313072230.GC3142@dell>

On 13/03/2020 07:22:30+0000, Lee Jones wrote:
> > > >  struct mt6397_rtc {
> > > >  	struct device           *dev;
> > > >  	struct rtc_device       *rtc_dev;
> > > > @@ -74,6 +80,7 @@ struct mt6397_rtc {
> > > >  	struct regmap           *regmap;
> > > >  	int                     irq;
> > > >  	u32                     addr_base;
> > > > +	const struct mtk_rtc_data *data;
> > > 
> > > 'data' is a terrible variable name.
> > > 
> > > Why do you need to store this?
> > > 
> > > It's one variable which is used once AFAICT.
> > 
> > I would rename 'data' to 'config'.
> > 
> > This struct will be extended in future patches to achieve more PMIC chip
> > compatibility.
> 
> On closer inspection, it looks like wrtgr (also not a great name for a
> variable by the way) is a register address.  Is that correct?
> Initially I thought it was a model number, which would have been a
> suitable candidate for entry into OF .data.
> 
> However, describing register addresses in OF .data does not sound like
> good practice.  It is usually used to identify a platform in the cases
> where platforms cannot be otherwise dynamically interrogated for model
> number via a register read.
> 
> Describing register maps via 'config' data is a slippery slope.

I'm not sure I get what you mean, there are dozens if not hundreds of
drivers doing it exactly that way. What is the difference between having
.data pointing to a register map and having .data containing a model
number and then use that model number to get the register map?

of_device_id::data definitively isn't config data as the DT describes
the hardware, not the configuration.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-03-13  7:47 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11  9:16 [PATCH v10 0/5] Add Support for MediaTek PMIC MT6358 Hsin-Hsiung Wang
2020-03-11  9:16 ` Hsin-Hsiung Wang
2020-03-11  9:16 ` Hsin-Hsiung Wang
2020-03-11  9:16 ` [PATCH v10 1/5] mfd: mt6397: modify suspend/resume behavior Hsin-Hsiung Wang
2020-03-11  9:16   ` Hsin-Hsiung Wang
2020-03-11  9:16   ` Hsin-Hsiung Wang
2020-03-11  9:17 ` [PATCH v10 2/5] dt-bindings: mfd: Add compatible for the MediaTek MT6358 PMIC Hsin-Hsiung Wang
2020-03-11  9:17   ` Hsin-Hsiung Wang
2020-03-11  9:17   ` Hsin-Hsiung Wang
2020-03-11  9:17 ` [PATCH v10 3/5] mfd: Add support " Hsin-Hsiung Wang
2020-03-11  9:17   ` Hsin-Hsiung Wang
2020-03-11  9:17   ` Hsin-Hsiung Wang
2020-03-12  1:41   ` Nicolas Boichat
2020-03-12  1:41     ` Nicolas Boichat
2020-03-12  1:41     ` Nicolas Boichat
2020-03-25  9:43   ` Lee Jones
2020-03-25  9:43     ` Lee Jones
2020-03-25  9:43     ` Lee Jones
2020-04-01  8:15     ` Hsin-hsiung Wang
2020-04-01  8:15       ` Hsin-hsiung Wang
2020-04-01  8:15       ` Hsin-hsiung Wang
2020-04-01  8:26     ` Hsin-hsiung Wang
2020-04-01  8:26       ` Hsin-hsiung Wang
2020-04-01  8:26       ` Hsin-hsiung Wang
2020-03-11  9:17 ` [PATCH v10 4/5] rtc: mt6397: Add support for the MediaTek MT6358 RTC Hsin-Hsiung Wang
2020-03-11  9:17   ` Hsin-Hsiung Wang
2020-03-11  9:17   ` Hsin-Hsiung Wang
2020-03-11 22:24   ` Sebastian Reichel
2020-03-11 22:24     ` Sebastian Reichel
2020-03-11 22:24     ` Sebastian Reichel
2020-03-12  1:47   ` Nicolas Boichat
2020-03-12  1:47     ` Nicolas Boichat
2020-03-12  1:47     ` Nicolas Boichat
2020-03-12  7:44   ` Lee Jones
2020-03-12  7:44     ` Lee Jones
2020-03-12  7:44     ` Lee Jones
2020-03-12  8:57     ` Ran Bi
2020-03-12  8:57       ` Ran Bi
2020-03-12  8:57       ` Ran Bi
2020-03-13  7:22       ` Lee Jones
2020-03-13  7:22         ` Lee Jones
2020-03-13  7:22         ` Lee Jones
2020-03-13  7:47         ` Alexandre Belloni [this message]
2020-03-13  7:47           ` Alexandre Belloni
2020-03-13  7:47           ` Alexandre Belloni
2020-03-13  8:30         ` Ran Bi
2020-03-13  8:30           ` Ran Bi
2020-03-13  8:30           ` Ran Bi
2020-03-11  9:17 ` [PATCH v10 5/5] arm64: dts: mt6358: add PMIC MT6358 related nodes Hsin-Hsiung Wang
2020-03-11  9:17   ` Hsin-Hsiung Wang
2020-03-11  9:17   ` Hsin-Hsiung Wang

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=20200313074734.GD3384@piout.net \
    --to=alexandre.belloni@bootlin.com \
    --cc=a.zummo@towertech.it \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=eddie.huang@mediatek.com \
    --cc=frank-w@public-files.de \
    --cc=hsin-hsiung.wang@mediatek.com \
    --cc=josef.friedl@speed.at \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=ran.bi@mediatek.com \
    --cc=rfontana@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=sean.wang@mediatek.com \
    --cc=sre@kernel.org \
    --cc=srv_heupstream@mediatek.com \
    --cc=tglx@linutronix.de \
    /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.