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: <op.vuallvn63ri7v4@arend-laptop>
Date:	Thu, 21 Apr 2011 16:38:09 +0200
From:	"Arend van Spriel" <arend@...adcom.com>
To:	"Arnd Bergmann" <arnd@...db.de>
cc:	"zajec5@...il.com" <zajec5@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"b43-dev@...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 Thu, 21 Apr 2011 16:12:49 +0200, Arnd Bergmann <arnd@...db.de> wrote:

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

Ok. that can be arranged ;-)

>> +/* 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.

Fine. Your providing the kind of feedback I was looking for. The  
OFDM_CORE_ID is also an exception.

So could a device driver claim multiple cores/devices to assure other  
drivers are not accessing those? I would prefer that over having  
exceptions coded in the axi bus driver, like the chipcommon core  
(CC_CORE_ID). I assume it can be done by the device table. Is that correct?

Rafał,

Would it be possible to make chipcommon driver optional (not doing the  
initialization)?

Gr. AvS
-- 
"The world is indeed comic, but the joke is on mankind." — H.P. Lovecraft

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