linux-kernel - Re: [PATCH] drivers: brcmaxi: provide amba axi functionality in separate module

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: <201104211612.49805.arnd@arndb.de>
Date:	Thu, 21 Apr 2011 16:12:49 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Arend van Spriel" <arend@...adcom.com>
Cc:	zajec5@...il.com, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, b43-dev@...ts.infradead.org,
	"George Kashperko" <george@...u.edu.ua>,
	"Jonas Gorski" <jonas.gorski@...il.com>,
	"Hauke Mehrtens" <hauke@...ke-m.de>,
	"Russell King" <rmk@....linux.org.uk>,
	"Larry Finger" <Larry.Finger@...inger.net>,
	"Andy Botting" <andy@...ybotting.com>, "Greg KH" <greg@...ah.com>,
	"Michael Buesch" <m@...s.ch>
Subject: Re: [PATCH] drivers: brcmaxi: provide amba axi functionality in separate module

On Wednesday 20 April 2011, Arend van Spriel wrote:
> The open-source community is looking for a library which will detect
> cores in a chip using axi backplane. Another proposal has been
> sent by Rafał Miłecki, which registers detected cores in the linux
> device tree to be claimed by device drivers. This implies cores will
> always provide a system function to the kernel which is indepent from
> other cores and have very loose or no coupling. If this is not true,
> exceptions need to be added in the device registration process. This
> means knowledge of specific devices from specific vendors is sitting
> in a bus driver. Whether the exceptions are rarely or likely is a
> pending question.

Hi Arend,

I have two very general comments about this:

> To feed the discussion this implementation takes a different approach.
> A calling entity (being a pci device driver, or SoC initialization
> sequence) registers a table with core identities and a callback function.
> It then starts the scan and for each detected core with a callback
> function it does the call providing the core information. Apart from
> that it provides some basic operations on the core.
> 
> It has been tested using the brcmsmac driver (in drivers/staging/brcm80211).

The API split between PCI and non-PCI devices appears to be
unhelpful. Can't you abstract the interface so that a user
would apply the exact same interfaces in both cases, and handle
the differences internally?

> +/* Core Codes */
> +#define	NODEV_CORE_ID		0x700	/* Invalid coreid */
> +#define	CC_CORE_ID		0x800	/* chipcommon core */
> +#define	ILINE20_CORE_ID		0x801	/* iline20 core */
> +#define	SRAM_CORE_ID		0x802	/* sram core */
> +#define	SDRAM_CORE_ID		0x803	/* sdram core */
> +#define	PCI_CORE_ID		0x804	/* pci core */
> +#define	MIPS_CORE_ID		0x805	/* mips core */
> +#define	ENET_CORE_ID		0x806	/* enet mac core */
> +#define	CODEC_CORE_ID		0x807	/* v90 codec core */
> +#define	USB_CORE_ID		0x808	/* usb 1.1 host/device core */
> +#define	ADSL_CORE_ID		0x809	/* ADSL core */
> +#define	ILINE100_CORE_ID	0x80a	/* iline100 core */
> +#define	IPSEC_CORE_ID		0x80b	/* ipsec core */
> +#define	UTOPIA_CORE_ID		0x80c	/* utopia core */
> +#define	PCMCIA_CORE_ID		0x80d	/* pcmcia core */
> +#define	SOCRAM_CORE_ID		0x80e	/* internal memory core */
> +#define	MEMC_CORE_ID		0x80f	/* memc sdram core */
> +#define	OFDM_CORE_ID		0x810	/* OFDM phy core */
> ...

This list to me is a strong hint that the cores behind the AXI bridge
should normally be actual devices in Linux, i.e. the approach that
Rafał suggested.  The vast majority of these is something that in Linux
would be operated by a device driver. The exceptions that I can see
are CPU cores and bus bridges, both of which we typically also represent
as devices in the flattened device tree, even though they typically
don't have a Linux driver attached to them.

	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/