Kumar Gala wrote: > > On Jun 15, 2005, at 10:31 AM, Vitaly Bordug wrote: > >> Kumar Gala wrote: >> >>> >>> On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote: >>> >>>> 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
