On Tue, Feb 22 2011, Nicolas Pitre wrote: > And if someone else comes up with a SSBI interface, then it will be much > easier to notice the already existing driver if it is in the driver > directory rather than somewhere else in some unrelated (from that > person's pov) obscure directory. Well, I'm fairly sure that nobody would be making an SSBI interface, but point taken. >> It seems kind of unusual to create an entirely new directory under >> drivers to hold what will only ever be a single driver. > > Well, a couple examples exist already: drivers/dca, drivers/nfc, > drivers/sn, drivers/tc, drivers/vlynq, etc. And if you expect to have > more oddball msm drivers then you can create a drivers/msm directory, > similar to the existing drivers/macintosh, drivers/parisc, drivers/s390, > drivers/sh, drivers/video/omap, drivers/video/omap2, etc. drivers/msm seems like a reasonable place. We already have other drivers that are in appropriate places. So what kinds of things constitute drivers versus arch-specific code? Currently, iommu drivers seem to be sprinkled throughout arch. We also have a shared-memory driver-type thing that is only used by other drivers. Does that make sense to be in drivers/msm? Ken, do you mind moving this driver into 'drivers/msm' as the first one there? Thanks, David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
