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] [day] [month] [year] [list]
Date:	Wed, 8 Sep 2010 20:39:08 -0700
From:	Greg KH <greg@...ah.com>
To:	Tony Lindgren <tony@...mide.com>
Cc:	David Cross <david.cross@...ress.com>,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related

On Wed, Sep 08, 2010 at 10:28:45AM -0700, Tony Lindgren wrote:
> * Greg KH <greg@...ah.com> [100907 17:17]:
> > On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote:
> > > This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch 
> > > is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am
> > > hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know 
> > > if there are any issues or concerns with this patch.
> > > Thanks,
> > > David
> > > 
> > > Signed-off-by: David Cross <david.cross@...ress.com>
> > > 
> > > diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c
> > > --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c	2010-08-31 19:32:51.000000000 -0700
> > > +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c	2010-09-01 16:10:21.000000000 -0700
> > > @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx, 
> > >  	reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
> > >  	__raw_writel(val, reg_addr);
> > >  }
> > > +EXPORT_SYMBOL(gpmc_cs_write_reg);
> > 
> > EXPORT_SYMBOL_GPL() perhaps?
> > 
> > What about platforms that don't have this symbol, how will the driver
> > build properly then?  Shouldn't something like this be in a arch-neutral
> > place in the kernel tree?
> 
> I don't think exporting these functions is a good idea, so NAK from
> me for that.
> 
> All the drivers should be generic, and whatever needs to be done
> that's omap specific should be done in the platform init code.

Ah, that makes more sense.  David, care to make those changes?

thanks,

greg k-h
--
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