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]

Date:	Tue, 12 Apr 2011 20:59:32 +0200
From:	Rafał Miłecki <zajec5@...il.com>
To:	George Kashperko <george@...u.edu.ua>
Cc:	balbi@...com, 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>,
	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>
Subject: Re: [RFC][PATCH] axi: add AXI bus driver

2011/4/12 George Kashperko <george@...u.edu.ua>:
>
>> 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.

I don't know, I'm really tired of this. Earlier I was told to not use
anything like bcmai, because it is not Broadcom specific. Now it seems
(and I'm afraid I agree) there is quite a lot of Broadcom specific
stuff.


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

We have got ideas, but let's first find (wait for) such a device ;)


> Any plans on embeddables' support ?

Sure, if noone will come before me, I'll try to provide support for
embedded devices. However basic support for PCI host in higher on my
priority list. First I want to know it is working at all ;)

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