linux-kernel - Re: [RFC][PATCH] bcmai: introduce AI 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: <1302124846.20093.16.camel@maggie>
Date:	Wed, 06 Apr 2011 23:20:46 +0200
From:	Michael Büsch <mb@...sch.de>
To:	Rafał Miłecki <zajec5@...il.com>
Cc:	Arend van Spriel <arend@...adcom.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>,
	Larry Finger <Larry.Finger@...inger.net>,
	George Kashperko <george@...u.edu.ua>,
	"b43-dev@...ts.infradead.org" <b43-dev@...ts.infradead.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Russell King <rmk@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	linuxdriverproject <devel@...uxdriverproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] bcmai: introduce AI driver

On Wed, 2011-04-06 at 23:12 +0200, Rafał Miłecki wrote: 
> W dniu 6 kwietnia 2011 23:08 użytkownik Michael Büsch <mb@...sch.de> napisał:
> > On Wed, 2011-04-06 at 23:01 +0200, Rafał Miłecki wrote:
> >> W dniu 6 kwietnia 2011 22:57 użytkownik Michael Büsch <mb@...sch.de> napisał:
> >> > On Wed, 2011-04-06 at 22:42 +0200, Rafał Miłecki wrote:
> >> >> 2011/4/6 Rafał Miłecki <zajec5@...il.com>:
> >> >> > If we want to have two drivers working on two (different) cores
> >> >> > simultaneously, we will have to add trivial mutex to group core
> >> >> > switching with core operation (read/write).
> >> >>
> >> >> With a little of work we could avoid switching and mutexes on no-host
> >> >> boards. MMIO is not limited to one core at once in such a case.
> >> >
> >> > I don't think that this is a problem at all.
> >> > All that magic does happen inside of the bus I/O handlers.
> >> > Just like SSB does it.
> >> > From a driver point of view, the I/O functions just need to
> >> > be atomic.
> >> >
> >> > For SSB it's not always 100% atomic, but we're always safe
> >> > due to some assumptions being made. But this is an SSB implementation
> >> > detail that is different from AXI. So don't look too closely
> >> > at the SSB implementation of the I/O functions. You certainly want
> >> > to implement them slightly differently in AXI. SSB currently doesn't
> >> > make use of the additional sliding windows, because they are not
> >> > available in the majority of SSB devices.
> >> >
> >> > The AXI bus subsystem will manage the sliding windows and the driver
> >> > doesn't know about the details.
> >>
> >> Sure, I've meant mutex inside bcmai (or whatever name), not on the driver side!
> >>
> >> In BCMAI:
> >> bcmai_read() {
> >> mutex_get();
> >> switch_core();
> >> ioread();
> >> mutex_release();
> >> }
> >
> > Yeah that basically is the idea. But it's a little bit harder than that.
> > The problem is that the mutex cannot be taken in interrupt context.
> > A spinlock probably is a bit hairy, too, depending on how heavy
> > a core switch is on AXI.
> >
> > On SSB we workaround this with some (dirty but working) assumptions.
> >
> > On AXI you probably can do lockless I/O, if you use the two windows
> > (how many windows are there?) in a clever way to avoid core switching
> > completely after the system was initialized.
> 
> We have 2 windows. I didn't try this, but let's assume they have no
> limitations. We can use first window for one driver only, second
> driver for second driver only. That gives us 2 drivers simultaneously
> working drivers. No driver need to reset core really often (and not
> inside interrupt context) so we will switch driver's window to agent
> (from core) only at init/reset.

On SSB one major assumption is that on non-embedded no coreswitch will
happen after init. (On embedded, the I/O accesses are safe anyway,
because all cores are always mapped).

> The question is what amount of driver we will need to support at the same time.

I guess (guess!) that the answer will be similar to SSB:
On non-embedded after init only one core is accessed: The wireless core.
And on embedded cores are accessed in random order. But it's safe
because the MMIO is always mapped.
Does this also apply to AXI?
Even if we would need to access two cores after init (wireless and
chipcommon, perhaps), we would use the two windows to survive without
an actual core switch while running.

-- 
Greetings Michael.

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