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]

Date:	Thu, 21 Apr 2011 16:50:09 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Arend van Spriel" <arend@...adcom.com>
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 Thursday 21 April 2011, Arend van Spriel wrote:
> >
> > 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?

You can bind any number of devices to one driver, and the match table
can contain entries for different classes of devices. You can also
have multiple drivers list the same ID and return an error from the
probe() function for those devices that don't actually match the
driver, based on additional properties. E.g you could have multiple
ethernet drivers bind to ENET_CORE_ID, but then have each one check
if the ethernet hardware is actually the one that the driver was written
for.

A much harder thing to do would be having one device managed by multiple
drivers simultaneously. This usually requires to have some kind of abstraction
driver that provides interfaces to other drivers, or something like MFD that creates
devices as children of the main device, and lets those be bound to individual
drivers.

	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/