-----Original Message----- From: Holger Brunck [mailto:holger.brunck@keymile.com] Sent: 09 July 2012 17:34 To: Prafulla Wadaskar Cc: Detlev Zundel; Valentin Longchamp; u-boot@lists.denx.de Subject: Re: [PATCH 12/20] arm/km: add support for external switchconfiguration
...snip...
Hi Detlev Clear NAK for this patch
Let's put it in drivers/net/phy/ FYI: there are several drivers used by just one board, [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim
drivers/net/phy/Makefile
[prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn
"CONFIG_PHY_ATHEROS" include/configs/*
include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS
1
[prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim
drivers/net/phy/Makefile
[prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn
"CONFIG_PHY_BROADCOM" include/configs/*
include/configs/microblaze-generic.h:347:# define
CONFIG_PHY_BROADCOM 1
Anyways peripheral driver should go in drivers/
yes there are maybe drivers which proof your concept, but there are many others in the board related code which do the opposite.
But I think this topic should be discussed not in the context of this patch. It's a general question. I 100% agree with Detlev's explanation. If a new very limited HW driver is added to the repo I see good reasons to keep it in the folder for the board. If a second user comes up and wants to enhance the driver for his needs he can still move driver then. But if no other user for this driver is there and maybe in the future the board needs to be removed because it's broken it's much easier to remove _all_ related code when it's located in one directory. If the code is spread over several directories it's much harder to track.
Dear Holger, The peripheral (switch/PHY) is being considered to be supported as a driver is interfaced through standard interface and can be used by any other CPU/architecture/SoC on any other board.
So I think there is no reason to keep it in board specific folder. Someone may correct me if I am wrong.
Copying Joe (net custodian)
Regards... Prafulla . . .