Re: [PATCH 2/7] Split S3C generic and S3C24xx specific code

[Juergen Beisert <jbe@pengutronix.de>]

Alexey Galakhov wrote:
> 2012/5/17 Sascha Hauer <s.hauer@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/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox