> Hi Kumar, > > I dont really know the policy for driver placement, but it seems that > it works on a case by case basis. > > The files in arch/ppc/8xx_io/ (which is what I think you refer to as > candidates for drivers/), are:
We have been slowly working on moving drivers out of arch/ppc and into drivers/ so that subsystem maintainers could get proper review of them. > 1) commproc.c > Basic API for dpram access. Core code. > > 2) micropatch.c > microcode update code/data. Core code. Well #1 & #2 aren't what I would call drivers at all. I would consider them syslib/ candidates. Hopefully, someone will > > 3) cs4218.h > 4) cs4218_tdm.c > > cs4218 does not compile at the moment due to syntatical problems, > I've fixed them up and the driver compiles, but I don't know > if it works (patch attached). > > I would not be surprised if the driver has been broken since > long time ago. > > Does anyone have hardware to test it? Dan? > > Otherwise we should remove it from the tree, since its unmaintained > and unused. If its still good, I would guessing /drivers/audio or snd, but neither seem to exist. I wondering where sound card drivers live these days. > > 5) enet.c > 6) fec.c > > The ENET/FEC network drivers are obseleted by fs_enet. > > However there are some PHY descriptions in fec.c which are missing > from > fs_enet - we'd better make sure to have them all in the new driver > before removing the old one. Agreed. > Aris, would you mind looking into this? > > Once we have that we can set a deadline at Documentation/feature- > removal.txt > if desired. > > Other than those there are no 8xx drivers in arch/ppc/ AFAIK. > > <cs42.patch> Good deal. Are we really removing anything (except maybe cs4218)? - kumar
