linux-kernel - Re: [PATCH] atmel_serial: update the powersave handler to match serial core

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: <20080919203520.2969dffd@hskinnemo-gx745.norway.atmel.com>
Date:	Fri, 19 Sep 2008 20:35:20 +0200
From:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
To:	Michael Trimarchi <trimarchimichael@...oo.it>
Cc:	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andrew Victor <linux@...im.org.za>,
	Anti Sullin <anti.sullin@...ecdesign.ee>
Subject: Re: [PATCH] atmel_serial: update the powersave handler to match
 serial core

Michael Trimarchi <trimarchimichael@...oo.it> wrote:
> > I agree it would be useful. It would require changing the port mux
> > configuration from the driver though, and there's no standardized
> > interface for doing that. Maybe this is a good motivation to come up
> > with one?
> >   
> 
> I think that a driver can do the request to a the gpio layer (may can be implemented
> by the gpio-lib ) and give it only the gpio. The "gpio-lib" can save and restore
> the status of the gpio, and request the handler, passing the gpio-id as 
> a data. So when the handler fire, we can now which peripheral is
> interested on the wake-up event.

I don't think the gpio layer is supposed to touch the portmux. David
has always been very clear about that. But if we somehow manage to get
the pin configured as a GPIO, we can use the GPIO layer to request a
pin change interrupt.

It _might_ work even if you don't reconfigure the pin as a GPIO...but
then I think we'd be relying on undocumented behaviour.

> > Btw, I assume the first character you receive will be lost when you do
> > this, right?
> >  
> 
> Yes, I haven't done a lot of test to see how many chars are lost (sure one I think). 
> Depends on the time spent after
> 
>  /* Wait for interrupt to wake us up */ 
>   mcr p15, 0, r0, c7, c0, 4 

Yes, we need to reach the atmel_serial resume handler before the UART
gets any chance to recognize the character. It's probably too late for
the first one, but it may catch the next one assuming the baud rate
isn't too high.

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