Thread (8 messages) 8 messages, 7 authors, 2009-04-20

RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

From: Stephen Neuendorffer <hidden>
Date: 2009-04-20 05:52:03

My thinking is that these drivers are likely to be used as a group,
hence it would be nice to make it easy to get them all visible/enabled somehow.

Steve

-----Original Message-----
From: John Williams [mailto:john.williams@petalogix.com]
Sent: Sun 4/19/2009 4:03 PM
To: microblaze-uclinux@itee.uq.edu.au
Cc: grant.likely@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-kernel@vger.kernel.org; John Linn
Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
 
On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
[off-list ref] wrote:

On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely [off-list ref]
wrote:
quoted
On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
[off-list ref] wrote:
quoted
Can we have XILINX_DRIVERS, please?  That way this can also be enabled
on any architecture that has FPGA peripherals.
I've thought about this more, and I'd really rather not.  The list of
affected drivers is short and is not a large maintenance burden.  I
don't think a list of 2 or 3 architecture selects for each driver is
unreasonable.  A "XILINX_DRIVERS" config item doesn't really help much
anyway.  At any given time one of these drivers may be needed on
another platform.  ie. the SystemACE device is present on at least one
non-virtex, non-spartan platform.
Which is exactly why having it architecture dependent isn't right...  All of
these drivers
could be needed and used on any OF-based platform.  If you have a platform
(for instance, a processor connected to an FPGA which has these peripherals
in the FPGA) then you should be able to enable these drivers.  Just my 2
cents...
What about the radical approach of having NO architecture
filters/selectors?  Even if some random i386 user selects one of these
drivers, so what?  It will still compile cleanly (if it doesn't we
have to fix it), but there'll be no platform_device_register() call in
their machine startup to actually cause driver / device binding.

No harm, no foul.  Problem goes away.

Then, as Grant points out, the rare cases where non-Xilinx platforms
do use this stuff, they'll presumably know what they're doing and it's
their responsibility to register the appropriate platform_device
structures and make the magic happen.

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663




This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help