linux-kernel - Re: [PATCH v2 01/13] mfd: pruss mfd driver.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110222113310.GD30279@sortiz-mobl>
Date:	Tue, 22 Feb 2011 12:33:11 +0100
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	Wolfgang Grandegger <wg@...ndegger.com>
Cc:	Subhasish Ghosh <subhasish@...tralsolutions.com>,
	sachi@...tralsolutions.com,
	davinci-linux-open-source@...ux.davincidsp.com, nsekhar@...com,
	open list <linux-kernel@...r.kernel.org>, m-watkins@...com,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 01/13] mfd: pruss mfd driver.

On Tue, Feb 22, 2011 at 11:48:51AM +0100, Wolfgang Grandegger wrote:
> On 02/22/2011 11:31 AM, Samuel Ortiz wrote:
> > Hi Subhasish,
> > 
> > On Tue, Feb 22, 2011 at 11:13:38AM +0530, Subhasish Ghosh wrote:
> >> Thank you for your comments.
> > No problem.
> > 
> >>>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >>>> index fd01836..6c437df 100644
> >>>> --- a/drivers/mfd/Kconfig
> >>>> +++ b/drivers/mfd/Kconfig
> >>>> @@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
> >>>>   boards.  MSP430 firmware manages resets and power sequencing,
> >>>>   inputs from buttons and the IR remote, LEDs, an RTC, and more.
> >>>>
> >>>> +config MFD_DA8XX_PRUSS
> >>>> + tristate "Texas Instruments DA8XX PRUSS support"
> >>>> + depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
> >>> Why are we depending on those ?
> >>
> >> SG -- The PRUSS core in only available within DA850 and DA830,
> >>            DA830 support is not yet implemented.
> > Sure, but if there are no actual code dependencies, I'd like to get rid of
> > those depends.
> > 
> >>>> +u32 pruss_disable(struct device *dev, u8 pruss_num)
> >>>> +{
> >>>> + struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
> >>>> + da8xx_prusscore_regs h_pruss;
> >>>> + u32 temp_reg;
> >>>> +
> >>>> + if (pruss_num == DA8XX_PRUCORE_0) {
> >>>> + /* Disable PRU0  */
> >>>> + h_pruss = (da8xx_prusscore_regs)
> >>>> + ((u32) pruss->ioaddr + 0x7000);
> >>> So it seems you're doing this in several places, and I have a few
> >>> comments:
> >>>
> >>> - You don't need the da8xx_prusscore_regs at all.
> >>> - Define the register map through a set of #define in your header file.
> >>> - Use a static routine that takes the core number and returns the
> >>> register map
> >>> offset.
> >>>
> >>> Then routines like this one will look a lot more readable.
> >>
> >> SG -- There are a huge number of PRUSS registers. A lot of them are
> >> reserved and are expected to change as development on the
> >>            controller is still ongoing. 
> > First of all, from what I read in your patch you're only using the CONTROL
> > offset.
> > 
> >> If we use #defines to plot
> >> all the registers, then first, there are too many array type
> >> registers which will need to be duplicated.
> > What I'm expecting is a small set of defines for the register offsets. You
> > have 13 fields in your da8xx_prusscore_regs, you only need to define 13
> > register offsets.
> > 
> > So, if you have a:
> > 
> > static u32 reg_offset(struct device *dev, u8 pru_num)
> > {
> > 	struct da8xx_pruss *pru = dev_get_drvdata(dev->parent);
> > 
> > 	switch (pru_num) {
> > 	case DA8XX_PRUCORE_0:
> > 		return (u32) pru->ioaddr + 0x7000;
> > 	case DA8XX_PRUCORE_1:
> > 		return (u32) pru->ioaddr + 0x7800;
> > 	default:
> > 		return 0;
> > }
> > 
> > 
> > then routines like pruss_enable (which should return an int, btw) would look
> > like:
> > 
> > int pruss_enable(struct device *dev, u8 pruss_num)
> > {
> > 	u32 offset = reg_offset(dev, pruss_num);
> > 
> > 	if (offset == 0)
> > 		return -EINVAL;
> > 
> > 	__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
> > 			offset + PRU_CORE_CONTROL);
> > 
> > 	return 0;
> > }
> 
> All registers are memory mapped and could nicely be described by
> structures (and sub-structures). Therefore we asked to considerer
> structs, at least for the Pruss SocketCAN drivers. 
>
> That would result in
> much much clearer and better readable code. The code above would shrink to:
> 
> 	__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
> 		     &prucore[pruss_num].control);
This driver seems to exclusively use the control offset, which is why I don't
see an absolute need for doing this mapping.
But if both maps are contiguous then doing the mapping would prevent us from
calling reg_offset() and would bring some advantage. I'd then be fine with it.
For now, da8xx_prusscore_regs seems to be larger than the 0x800 interval
between the 2 maps, so I have no idea if both maps are indeed contiguous.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/