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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 22 Jun 2010 16:53:45 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Linus Walleij <linus.walleij@...ricsson.com>
Cc:	linux-kernel@...r.kernel.org, Viresh Kumar <viresh.kumar@...com>
Subject: Re: [PATCH] DMAENGINE: runtime config for slave channels

On Sun, Jun 20, 2010 at 3:19 PM, Linus Walleij
<linus.walleij@...ricsson.com> wrote:
> This adds an interface to the DMAengine to make it possible to
> reconfigure a channel at runtime. We add a few foreseen config
> parameters to the passed struct, with a void * pointer for custom
> per-device or per-platform data.
>
> Cc: Viresh Kumar <viresh.kumar@...com>
> Signed-off-by: Linus Walleij <linus.walleij@...ricsson.com>
> ---
> OK at night I realized that maybe what we do for runtime
> re-configuration of DMA for the AMBA PrimeCells is actually generic
> and should maybe be lifted into the DMAengine instead.
>
> This conclusion came from Viresh stating that the SPEAr platform
> will need runtime reconfiguration for other things than PrimeCells,
> (on the PL08x driver) and actually we will likely need it ourselves
> too.
>
> So before starting to abuse that PrimeCell interface for things
> not PrimeCell, this way I suggest making this generic from day 1.
>
> Doing so makes it possible for me to merge the runtime
> re-configuration support for DMA40, COH 901 318 and the current
> iteration of the PL08x driver as well, and break that out of the
> PrimeCell series and drop the include/linux/amba/dma.h entirely
> while still getting some real nice and generic functionality
> in place.
>
> The PrimeCell patchset can then be nicely wrapped around this.
>
> More genric run-time configurations can be added to the struct if
> they are really generic like these, else the private_config can
> be used for local obscurities.
>
> Need your help on how to proceed on this one Dan.

Is there a guarantee that all devices that implement this command will
support all the fields?  The presence of private_config concerns me
because that still seems to imply some hard coded knowledge about the
specific dma engine from the client.

...which is fine, but only if this is a common way to express
arch-specific extensions.  In other words it's not clear where the
line is drawn between "this is a common operation that different dma
drivers can use / extend incompatibly" versus "this truly a generic
api that a client driver can depend on to run unmodified across
architectures that have a supporting dma driver".  Clarifying that
would help end point device driver authors to know what they can rely
on... to date all the slave implementations have been written by the
same author who wrote the driver, so the information hiding has been
blurred.  It would be nice to define / document what is and is not
expected to work for this command across implementations.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ