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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060802180023.65fe6434@cad-250-152.norway.atmel.com>
Date:	Wed, 2 Aug 2006 18:00:23 +0200
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	Andrew Victor <andrew@...people.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] at91_serial: support AVR32

On Wed, 2 Aug 2006 16:15:05 +0100
Russell King <rmk+lkml@....linux.org.uk> wrote:

> On Wed, Aug 02, 2006 at 04:51:46PM +0200, Haavard Skinnemoen wrote:
> > diff --git a/drivers/serial/at91_serial.c
> > b/drivers/serial/at91_serial.c index 54c6b2a..f2fecc6 100644
> > --- a/drivers/serial/at91_serial.c
> > +++ b/drivers/serial/at91_serial.c
> > @@ -40,8 +40,10 @@ #include <asm/arch/at91rm9200_usart.h>
> >  #include <asm/arch/at91rm9200_pdc.h>
> >  #include <asm/mach/serial_at91.h>
> >  #include <asm/arch/board.h>
> > +#ifdef CONFIG_ARM
> >  #include <asm/arch/system.h>
> 
> I'd rather this file wasn't included in any drivers in any case.

I suppose the cpu_is_*() stuff I've heard about through David Brownell
is going to solve that. Could someone point me at the patch
implementing it for ARM so that I can implement something similar for
AVR32?

> > @@ -611,7 +615,8 @@ static int at91_request_port(struct uart
> >  		return -EBUSY;
> >  
> >  	if (port->flags & UPF_IOREMAP) {
> > -		port->membase = ioremap(port->mapbase, size);
> > +		if (port->membase == NULL)
> > +			port->membase = ioremap(port->mapbase,
> > size);
> 
> This change makes no sense.  If you don't want ioremap, don't set
> UPF_IOREMAP.

It's supposed to prevent it from ioremap()ing it again if it was
previously ioremap()ed for use by the console. I'll drop it along with
the call to ioremap() in the next hunk.

> >  		if (port->membase == NULL) {
> >  			release_mem_region(port->mapbase, size);
> >  			return -ENOMEM;
> > @@ -693,12 +698,19 @@ static void __devinit at91_init_port(str
> >  	port->mapbase	= pdev->resource[0].start;
> >  	port->irq	= pdev->resource[1].start;
> >  
> > +#ifdef CONFIG_AVR32
> > +	port->flags |= UPF_IOREMAP;
> > +	port->membase = ioremap(pdev->resource[0].start,
> > +				pdev->resource[0].end
> > +				- pdev->resource[0].start + 1);
> 
> Don't see the requirement for this.

Well, maybe I misunderstood something. The reason I added it was to get
a pointer to the USART registers for use by the serial console. I guess
it would work equally well to just set UPF_IOREMAP, except that the
console will start working a bit later...

What is the best way to get the serial console up and running early in
the boot process? ioremap() only happens to work because the internal
peripherals are permanently mapped on AVR32, so I shouldn't really
depend on that.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ