Thread (26 messages) flat view 26 messages, 7 authors, 2005-06-16

Re: RFC: cpm2_devices.c

From: Vitaly Bordug <hidden>
Date: 2005-06-15 16:07:44

Kumar Gala wrote:
On Jun 15, 2005, at 10:31 AM, Vitaly Bordug wrote:
quoted
Kumar Gala wrote:
quoted
On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote:
quoted
Kumar,
I assume this as a IMMR enumerating you promised to help with. Is 
it in
the final state? And what was the reason of fcc_regs_c removal?
I'm also going to change the files name to cpm2_.. .


Yes, I removed the fcc_regs_c since its not always true.  Please don't
rename the file to cpm2_.  I think I'm going to end up renaming them
to pq2_ since that is the most appropriate name.  I'd say we are about
80% the way to a final patch.
Great. Apart of naming issue - what else remaining to do?
I mean how can I contribute to speed-up this?

At this point, I think a bit more discussion is going to be needed on 
if SI1, SI2, and CPM are "devices" or not.

Also, does the proposed FCC defn. sufficient or do we need the 
extended registers that exist on some of the newer PQ2/PQ3 devices?  I 
wasn't sure if the drivers used them or not.
fs_enet uses fcc_regs_c but only as a pass to the generic ethtool stuff 
but I'm not currently aware if it's compulsory. I guess FCC's mem(used 
to be IORESORCE) will be passed through platform_info but... Well, we 
have tiptridx etc. stuff that wants DPRAM offsets but pad area has to be 
real address. I'm still not sure how to handle this correct...
- kumar

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