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