linux-kernel - Re: [PATCH 1/1] Driver for the Atmel on-chip SSC on AT32AP and AT91.

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] [day] [month] [year] [list]

Message-Id: <200707190745.43151.david-b@pacbell.net>
Date:	Thu, 19 Jul 2007 07:45:42 -0700
From:	David Brownell <david-b@...bell.net>
To:	Haavard Skinnemoen <hskinnemoen@...el.com>
Cc:	Hans-Christian Egtvedt <hcegtvedt@...el.com>,
	Andrew Victor <andrew@...people.com>,
	kernel-avr32 <kernel@...32linux.org>,
	Patrice Vilchez <patrice.vilchez@....atmel.com>,
	Nicolas FERRE <nicolas.ferre@....atmel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] Driver for the Atmel on-chip SSC on AT32AP and AT91.

On Thursday 19 July 2007, Haavard Skinnemoen wrote:

> > So the protocol drivers need some kind of resource management in order
> > to not step on each others' toes, and that's the reason for the export
> > of ssc_request() and ssc_free().
> > 
> > I'm not sure if anyone would have been very mad at me for sneaking this
> > in through the avr32 tree, but I'd really like to know what others, in
> > particular the AT91 people and David, think of this kind of thing
> > before it ends up in mainline.

Does this work with both AT91 and AVR32 instances of SSC-to-at73c213
audio output hardware?  Clearly it "should".

This "kind of thing" seems pretty routine.  I see it all the time with
timer modules and DMA channels ... as well as flexible serial links like
this "SSC" module.  (Other serial-link examples include McBSP on OMAP,
SSP on PXA, and lots of non-AC97 audio data stream links.)

In this case a simple request/free interface is enough, since only one
module will hook up to the external hardware.  (Here, a Codec/AMP chip.)
In other cases the request may imply a more complex choice algorithm
than just matching IDs:  the particular DMA channel or timer returned
may not matter.  So for now I think hardware-specific APIs are OK.

Thing is, these don't fit very nicely into the driver model since not
all instances of that silicon module will use the same driver.  One
instance might manage a bidirectional audio stream through a codec;
another might implement the control interface to that code using SPI;
while a third might manage a custom data acquisition interface.

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