[PATCH 2/7] Split S3C generic and S3C24xx specific code
Juergen Beisert
jbe at pengutronix.de
Thu May 17 15:49:21 EDT 2012
Alexey Galakhov wrote:
> 2012/5/17 Sascha Hauer <s.hauer at pengutronix.de>:
> > Still you convert two different functions to a common name. Once again:
> > Please keep s3c24xx_get_memory_size and add a s5p_get_memory_size
> > function for the s5p SoC.
> > It turned out to be useful when functions (or defines) have a spcific
> > SoC name in them. This way you always know in which context a function
> > is valid. Also it makes it possible to compile in all (in this case
> > memory setup) functions in a single binary.
> > I know that we do not follow this rule very strictly in barebox, but I
> > won't accept patches that change places that do it right already.
>
> Ok. Sorry.
>
> BTW, there are functions like s3c_get_pclk(), and they are much worse
> than get_memory_size regarding their portability. Newer S3Cs have
> multiple clock domains, so there is more than one PCLK (i.e.,
> MSYS-PCLK and HSYS-PCLK). These functions are declared publilc, not
> static, in a header file. They all are used in S3C24x0-specific code
> only. Should they be renamed like s3c24xx_get_pclk() ? Should some of
> them become static?
Mostly a matter of taste. But sometimes these functions should use a common
name: when they are used by a shared driver.
If you call a S3C2440 related function by a S3C2440 related driver or board
file, we should use a SoC specific name. When we call a function from a
driver used for S3C2440 *and* S3C6410 it should use a non SoC specific name.
This is a "should" and I fear my S3C24xx code is not perfect in this way.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
More information about the barebox
mailing list