linux-kernel - Re: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related

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]

Date:	Wed, 8 Sep 2010 10:28:45 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Greg KH <greg@...ah.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

* 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.

If the driver needs to reconfigure something, such as memory timings,
it can be done by passing a retime function pointer to the driver
in the platform_data. Then the driver can call that function if
it exists.

Regards,

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