On Tue, 5 Mar 2013 22:22:09 -0800 Simon Glass <[email protected]> wrote:
> On Tue, Mar 5, 2013 at 9:04 PM, Kim Phillips <[email protected]> > wrote: > > On Tue, 5 Mar 2013 17:51:00 -0800 > > Simon Glass <[email protected]> wrote: > > > [snip for Kim] and others too, I hope. > >> >> Changes sice v3: > >> >> - Changed command names to lower case in algo struct. > >> >> - Added generic ace_sha config. > >> > > >> > I wouldn't call "ace" a generic name - crypto units other than > >> > ACE should be able to use this code. > >> > >> I don't really understand this comment. A new CONFIG has been added, > >> and this is specific to that unit. Are you suggesting that it be > > > > right, and that's the problem - it needn't be specific to that unit. > > Really? I think here we have a patch for an ACE unit, and currently > the only implementation is in an Exynos chip. It can easily be so make the ace_sha.o build depend on whichever level of chip config applies - CONFIG_S5P, CONFIG_EXYNOS5, or CONFIG_SMDK5250. No need for a new define specifically for ACE, right? > extended later when someone else has one. maybe, but we can try to avoid people copying existing code patterns, i.e. polluting common code when adding crypto routines for their h/w which are basically the same function declarations but with different names. > >> CONFIG_EXYNOS_ACE_SHA? Will the ACE unit not appear on any other SOC? > > > > my point is other SoCs can use the same entry in the array - there's > > nothing h/w-vendor or model-specific about it. > > OK, know you of such an SOC? I'm not familiar with Samsung crypto products, and I can't become familiar either, judging by the state of their public documentation (if a company doesn't make their crypto unit documentation public, that only has to mean something's insecure - and not just through obscurity :). A large majority of Freescale's PowerQUICC & QorIQ chips have crypto units. A lot of them have crypto as an option, so discovery has to be done at runtime (but we can add that later). The primary objective here is to not add h/w vendor dependencies in common areas when they can easily be avoided. > > Something like CONFIG_HW_SHA{1,256} ought to do it. > > > >> But I don't think crypto units other than ACE will use the code in > >> this patch - it is intended to implement ACE support, and put it ahead > >> of software support in terms of priority. > > > > the same priority that any h/w accelerated device would get - higher > > than that of software crypto. > > > > Another question for Akshay wrt the timeout (since I never got a > > reply re: documentation): how can the h/w fault? > > > > Kim > > > > oh, and please stop full-quoting - I'm tired of looking at my > > scrollbar go by with no inline content. > > I will try harder. You could look at trying another mailer :-) Thanks, I appreciate it. Gmail? just more clicking, no? Kim _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
