On Sat, 6 Oct 2012, Jean Delvare wrote:

quoted

The question is what drives the choice of where to put HID-over-XXX, among the following
 1- who the maintainer is. Here, Benjamin will probably maintain this 
so it does not help.
 2- dependencies. HID-over-XXX depends on HID as much as it depends on 
XXX, so it does not help.
 3- data flow. Indeed, HID is a client of HID-over-XXX which is a 
client of XXX. Are there other parts of the kernel where this drives 
the choice of where YYY-over-XXX lives?

Jiri, Marcel, Greg, others, any opinions?

My vote is a clear 3. It took me a few years to kick all users (as
opposed to implementers) of i2c from drivers/i2c and finding them a
proper home, I'm not going to accept new intruders. Grouping drivers
according to what they implement makes it a lot easier to share code
and ideas between related drivers. If you want to convince yourself,
just imagine the mess it would be if all drivers for PCI devices lived
under drivers/pci.

This is more or less consistent with my original opinion when I was 
refactoring the HID layer out of the individual drivers a few years ago.

But Marcel objected that he wants to keep all the bluetooth-related 
drivers under net/bluetooth, and I didn't really want to push hard against 
this, because I don't have really super-strong personal preference either 
way.

But we definitely can use this oportunity to bring this up for discussion 
again.

-- 
Jiri Kosina
SUSE Labs