On Wed, 2012-03-21 at 15:15 -0700, Greg KH wrote:
Really? vio drivers are supposed to look like this with the .name and
.owner field manually being set in the static initialization of the
driver? That's sad, and should be fixed, the vio core should do this
type of thing for you.
Yeah,
On Thu, 2012-03-22 at 12:50 +1100, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-21 at 15:15 -0700, Greg KH wrote:
Really? vio drivers are supposed to look like this with the .name and
.owner field manually being set in the static initialization of the
driver? That's sad, and should
On Wed, 2012-03-21 at 20:39 -0700, Greg KH wrote:
On Thu, Mar 22, 2012 at 01:57:30PM +1100, Benjamin Herrenschmidt wrote:
+int __vio_register_driver(struct vio_driver *viodrv, struct module *owner,
+ const char *mod_name)
{
viodrv-driver.bus = vio_bus_type
Hrm... I don't like that much:
+ if (op-timeout)
+ deadline = jiffies + msecs_to_jiffies(op-timeout);
+
+ while (true) {
+ hret = plpar_hcall_norets(H_COP, op-flags,
+ vdev-resource_id,
+ op-in,
Else, what about ceding the processor ? Or at the very least reducing
the thread priority for a bit ?
Shouldn't we also enforce to always have a timeout ? IE. Something like
30s or so if nothing specified to avoid having the kernel just hard
lock...
In general I don't like that sort of
On Mon, 2013-05-06 at 14:24 -0500, Kent Yoder wrote:
Hi Ben, just a friendly reminder to please apply.
Oh, I assumed that stuff was going via some drivers/crypto maintainer...
I can apply.
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a
On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote:
Signed-off-by: Fionnuala Gunter f...@linux.vnet.ibm.com
Signed-off-by: Joel Schopp jsch...@linux.vnet.ibm.com
Signed-off-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
Why that
On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote:
---
drivers/crypto/nx/nx-sha256.c | 108 +++-
drivers/crypto/nx/nx-sha512.c | 113
--
2 files changed, 129 insertions(+), 92 deletions(-)
What about the other
On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote:
This series of patches fixes two bugs that are triggered when the input data
is
too large. The first one is caused by the miscalculation of physical addresses
and the second one by some limits that the co-processor has to the input data.
On Wed, 2013-08-07 at 18:15 -0500, Fionnuala Gunter wrote:
This patch fixes a bug that is triggered when cts(cbc(aes)) is used with
nx-crypto driver on input larger than 32 bytes.
The chaining value from co-processor was not being saved. This value is
needed because it is used as the IV by
On Fri, 2017-05-05 at 15:52 +0200, Michal Suchánek wrote:
>
> So you have an e-mail message from one of the authors of the code.
> Andy Polyakov wrote most of the code but there are probably other
> contributors who never gave explicit consent for using their code
> outside of OpenSSL.
The only
On Tue, 2017-08-29 at 09:58 -0400, Dan Streetman wrote:
> > +
> > + ret = -EINVAL;
> > + if (coproc && coproc->vas.rxwin) {
> > + wmem->txwin = nx842_alloc_txwin(coproc);
>
> this is wrong. the workmem is scratch memory that's valid only for
> the duration of a single
On Tue, 2017-08-29 at 14:54 -0700, Haren Myneni wrote:
> Opening send window for each crypto transform (crypto_alloc,
> compression/decompression, ..., crypto_free) so that does not have to
> wait for the previous copy/paste complete. VAS will map send and
> receive windows, and can cache in send
13 matches
Mail list logo
