linux-kernel - Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

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>] [day] [month] [year] [list]

Date:	Mon, 20 Apr 2009 09:03:40 +1000
From:	John Williams <john.williams@...alogix.com>
To:	microblaze-uclinux@...e.uq.edu.au
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Stephen Neuendorffer <stephen.neuendorffer@...inx.com>,
	linuxppc-dev <linuxppc-dev@...abs.org>,
	linux-kernel@...r.kernel.org, John Linn <john.linn@...inx.com>
Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable 
	drivers for Microblaze

On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
<stephen.neuendorffer@...il.com> wrote:
>
>
> On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@...retlab.ca>
> wrote:
>>
>> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
>> <stephen.neuendorffer@...inx.com> wrote:
>> >
>> > 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
--
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/