lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 25 Jun 2012 16:26:08 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	balbi@...com
Cc:	"ABRAHAM, KISHON VIJAY" <kishon@...com>,
	Greg KH <gregkh@...uxfoundation.org>,
	grant.likely@...retlab.ca, rob.herring@...xeda.com,
	rob@...dley.net, linux@....linux.org.uk, b-cousson@...com,
	rnayak@...com, tony@...mide.com,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH v2 1/2] drivers: misc: omap: add a new driver for ocp2scp

On Monday 25 June 2012, Felipe Balbi wrote:
> > > Can't this live where the scp drivers live?  Actually, where is that at?
> > > Do we have scp drivers?
> > AFAIK, there isn't any driver for scp. But we have a driver for ocp
> > and it is present at arch/arm/mach-omap2/omap_l3_noc.c
> 
> I don't think this deserves a directory of its own. Maybe
> drivers/platform/arm/omap/ ?? the l3_noc is an OMAP-specific
> interconnect and the SCP bus is also an OMAP-specific bus. I don't know
> of any other arch/soc who uses the same interconnect IP as OMAP and the
> same ocp2scp bridge. That bridge was created by TI for all I know.
> 
> Greg, would drivers/platform/arm/omap/ work for you ? We could also move
> the interconnect drivers there.

I really don't like the idea of introducing drivers/platform/arm/ because
very little of the stuff that one would put in there are actually ARM
specific.

I have suggested a drivers/bus/ before and people did not see the need
back then, and we agreed to continue having a directory for each bus,
as we have for the big ones (pci, usb, i2c, spi, ...) and a lot of
simple (amba, rapidio, bcma, ...) or obscure (tc,  vlynq, nubus, ...)
ones.

I think we should reconsider the idea of drivers/bus/ with a file per
bus in there at least for new buses, but doing a new drivers/scp/
would be ok for me if there is enough opposition against the idea
of drivers/bus aggregating different buses.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ