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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=W8gt+xgsJ5pPz1uCXGubDHkOnXoDz0mq--cDvkdf-j9g@mail.gmail.com>
Date:	Fri, 1 Jul 2016 10:05:50 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	apronin@...omium.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS

Hi,

On Fri, Jul 1, 2016 at 1:21 AM, Mark Brown <broonie@...nel.org> wrote:
> On Thu, Jun 30, 2016 at 09:23:26PM -0700, Doug Anderson wrote:
>
>> Also, something doesn't seem terribly robust about this, buy maybe I'm
>> being paranoid.  If something happens where the timer hasn't fired
>> quickly enough then you might not know that you need to assert the
>> wakeup, right?  I don't think there's a 100% guarantee that a timer
>> will fire and finish running within a certain period of time, is
>> there?
>
> No, or at least a minimum bound on accuracy - you'd need to set the
> timer for something lower than the actual limit.

I'm curious why you you need a timer at all.  Can't you just keep
track of the jiffies that you last sent and do subtraction?  ...or you
could get even more accurate and use a ktime_t.  That avoids a whole
lot of synchronization / locking issues too...

Also: presumably you'll need to make sure that there's some margin in
this whole thing.  I'd imagine that if the timeout is 10000
nanoseconds and you do the calculation and you last sent 9999
nanoseconds ago then you might decide that the other side isn't asleep
yet.  ...but by the time the transfer starts it might be asleep...

-Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ