linux-kernel - Re: [PATCH] AT91: add AT91SAM9X5 dummy configuration variable

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:	Tue, 28 Jun 2011 18:02:52 +0200
From:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
To:	Felipe Balbi <balbi@...com>
Cc:	Nicolas Ferre <nicolas.ferre@...el.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	avictor.za@...il.com
Subject: Re: [PATCH] AT91: add AT91SAM9X5 dummy configuration variable

On 15:26 Tue 28 Jun     , Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jun 28, 2011 at 02:13:39PM +0200, Nicolas Ferre wrote:
> > Le 28/06/2011 12:35, Felipe Balbi :
> > > On Tue, Jun 28, 2011 at 01:35:27PM +0200, Nicolas Ferre wrote:
> > >> Add this Kconfig variable to ease the submission of this chip support.
> > >> As this chip/board inclusion is dealayed due to deep consolidation of
> > >> arm/mach-at91 sources, we include this dummy configuration variable to allow
> > >> submission of SAM9x5 related drivers in other subsystems.
> > > 
> > > Why are the drivers even depending on this ? They should be portable
> > > enough. Can you share a few drivers so we have a look ?
> > 
> > Yes sure. The dependence is only on the Kconfig side: I plan to make
> > some drivers dependent on this configuration variable.
> > The goal is to submit the final driver addition without having to send
> > again a correction to the Kconfig after the chip/board support is merged.
> 
> my point is that the drivers shouldn't need that ;-) Are the controllers
> Atmel's specific or are you guys sourcing from somewhere else ?
> 
> > This will ease the submission process at the cost of a two lines dummy
> > patch and will remove interdependence between subsystem trees: it worth
> > it, is not it?
> 
> if you remove any architecture dependency from the driver, why do you
> even need these two lines ? ;-)
> 
> > > IMHO, the whole idea of the consolidation is beyond arch/arm, drivers
> > > should be affected too.
> > 
> > Yes sure, I also understood like this.
> > I will not spread ARCH_AT91SAM9X5 ifdef in driver code...
> 
> yet you will prevent the driver from being easily used by other
> architectures. What will happen is that a certain amount of:
> 
> depends on (ARCH_AT91SAM9X5 || ARCH_FOO || ARCH_BAR || ARCH_BAZ)
no I disagree this is done to allow only the drivers on proper arch

and we do not need the multiple depend we usally create a HAVE_xxx config
that the ARCH select and we just depend on it


Best Regards,
J.
--
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/