Hi Kim, Thanks for comments. Please see inline.
James On Wed, 2008-10-29 at 10:54 -0500, Kim Phillips wrote: > On Tue, 28 Oct 2008 19:18:20 -0700 > James Hsiao <[EMAIL PROTECTED]> wrote: > > > On Tue, 2008-10-28 at 20:51 -0400, Josh Boyer wrote: > > > - The question on ABLKCIPHER kconfig was ignored > > Is ABLKCIPHER a sub set of BLKCIPHER? So, if BLKCIPHER is selected then > > if ABLKCIPHER is present, it will use ABLKCIPHER otherwise using > > BLKCIPHER algorithm? Correct? > > this is my bad, commit 653ebd9c8510a7d647ed23e66e1338f848ebdbab > "blkcipher: Merge ablkcipher and blkcipher into one option/module" > renders CRYPTO_ABLKCIPHER obsolete in favour of CRYPTO_BLKCIPHER. > Ok. > > > - Marking functions static > > We have more than one file, that is why some of the function are not > > static. > > have one file then? This is our first round of patch. We will support many more algorithms and it will have much more files. I am afraid one file will be way too big. > > > > - Global lsec_core variable which doesn't allow for more than one > > > device > > We only support single incidence of device. > > it's also a matter of unnecessarily polluting global namespace. > I look into modify this. > > > - Complete lack of locking code, how do you enforce mutually exclusive > > > access to the device? > > > > The crypto engine have couple bits 'command ready' and 'packet done', > > which servers as semaphore here. So, software don't need extra locking. > > know if it's applicable at all, but I imagine it's not SMP safe. No, it's not SMP safe. This driver only support single core processors. > > Kim _______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
