linux-kernel - Re: [RFC][PATCH] axi: add AXI bus driver

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]

Message-Id: <1302634039.14216.10.camel@dev.znau.edu.ua>
Date:	Tue, 12 Apr 2011 21:47:19 +0300
From:	George Kashperko <george@...u.edu.ua>
To:	balbi@...com
Cc:	linux-wireless@...r.kernel.org,
	"John W. Linville" <linville@...driver.com>,
	b43-dev@...ts.infradead.org,
	Michael Büsch <mb@...sch.de>,
	Larry Finger <Larry.Finger@...inger.net>,
	George Kashperko <george@...u.edu.ua>,
	Arend van Spriel <arend@...adcom.com>,
	linux-arm-kernel@...ts.infradead.org,
	Russell King <rmk@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Andy Botting <andy@...ybotting.com>,
	linuxdriverproject <devel@...uxdriverproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rafał Miłecki <zajec5@...il.com>
Subject: Re: [RFC][PATCH] axi: add AXI bus driver


> Hi,
> 
> On Tue, Apr 12, 2011 at 01:57:07AM +0200, Rafał Miłecki wrote:
> > Cc: Michael Büsch <mb@...sch.de>
> > Cc: Larry Finger <Larry.Finger@...inger.net>
> > Cc: George Kashperko <george@...u.edu.ua>
> > Cc: Arend van Spriel <arend@...adcom.com>
> > Cc: linux-arm-kernel@...ts.infradead.org
> > Cc: Russell King <rmk@....linux.org.uk>
> > Cc: Arnd Bergmann <arnd@...db.de>
> > Cc: Andy Botting <andy@...ybotting.com>
> > Cc: linuxdriverproject <devel@...uxdriverproject.org>
> > Cc: linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>
> > Signed-off-by: Rafał Miłecki <zajec5@...il.com>
> > ---
> > V2: Rename to axi
> >     Use DEFINE_PCI_DEVICE_TABLE in bridge
> >     Make use of pr_fmt and pr_*
> >     Store core class
> >     Rename bridge to not b43 specific
> >     Replace magic 0x1000 with BCMAI_CORE_SIZE
> >     Remove some old "ssb" names and defines
> >     Move BCMAI_ADDR_BASE def
> >     Add drvdata field
> > V3: Fix reloading (kfree issue)
> >     Add 14e4:0x4331
> >     Fix non-initialized struct issue
> >     Drop useless inline functions wrappers for pci core drv
> >     Proper pr_* usage
> > V3.1: Include forgotten changes (pr_* and include related)
> >     Explain why we dare to implement empty release function
> 
> I'm not sure we need this. If you have an IP Core which talks AXI and
> you want to put it on a PCI bus, you will have a PCI Bus wrapper around
> that IP Core, so you should go and let the kernel know about that. See
> [1] for a core IP which talks AXI and [2] for a PCI bus glue layer.
> 
> Besides, if you introduce this bus layer, it'll be more difficult for
> other licensees of the same core to re-use the same driver, since it's
> now talking a PCI emulated on top of AXI. The same can be achieved with
> the platform_bus which is more widely used, specially on ARM SoCs.
> 
> [1] http://gitorious.org/usb/usb/blobs/dwc3/drivers/usb/dwc3/core.c
> [2] http://gitorious.org/usb/usb/blobs/dwc3/drivers/usb/dwc3/dwc3-haps.c
> 

Already noticed earlier that AXI isnt really good name for
Broadcom-specific axi bus customization. As of tech docs available from
arm, corelink AXI cores use own identification registers which feature
different format and layout comparing to that we use for Broadcom cores.

Maybe there is something "standartized" by the DMP specs? If so I'm
curious if that DMP is obligatory for every axi bus ?

Naming particular Broadcom's implementation just axi limits other
licensees in reusing axi bus name/code or will require hacks/workarounds
from them to fit Broadcom-like core scanning/identificating techniques.
You use bus named AXI to group and manage Broadcom cores, while never
even publish device records for native axi cores Broadcom use to talk to
the interconnect through. Yet again, something like bcmb/bcmai looks
like better name for this bus.

Also can't figure out how is this implementation supposed to manage
multicore devices.

Any plans on embeddables' support ?

Have nice day,
George


--
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/