Thread (4 messages) flat view 4 messages, 2 authors, 2006-06-24

Re: [PATCH 5/6] CPM_UART: unify clock sources

From: Kumar Gala <hidden>
Date: 2006-06-24 15:50:14

Possibly related (same subject, not in this thread)

On Jun 24, 2006, at 10:21 AM, Vitaly Bordug wrote:
Kumar,

Thanks for feedback! My comment below.

On Sat, 24 Jun 2006 08:46:54 -0500
Kumar Gala [off-list ref] wrote:

[snip]
quoted
quoted
+
+#ifndef FS_PD_H
+#define FS_PD_H
+
+#define GET_BAUDRATE()	(((bd_t *) __res)->bi_baudrate ?
((bd_t *) __res)->bi_baudrate : -1)
+#define FS_UART_CLK()	(((bd_t *) __res)->bi_intfreq)
+
+#endif
We shouldn't hide these differences in a header like this.  As we
slowly try to removing things from arch/ppc.  Why not just add
platform data for these two pieces of data and set it up like we do
other platform data.
That was my first guess as well, but:
The aim is yet moving to powerpc not to break existing ppc/ stuff.
So if alternatively platform_data may be utilized, all relevant ppc
stuff that uses cpm uart should be updated. While doing the driver
"platformize" trick, I made it possible to keep legacy behaviour
(pd-less), this is not going to afford such a thing.

IOW, I don't see much sense in updating ppc/ BSP files, just to keep
the right way. It does not look very neat now, but does the job of
moving FW and keeping existing stuff sane. If there is better approach
envisioned, I'll definitely follow..
Fair enough, then I would suggest getting ride of all this header/ 
MACRO indirection and just implement these as functions with  
different implementations in arch/powerpc vs arch/ppc.

- k
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help