linux-kernel - Re: [PATCH] x86/platform: sta2x11: add platform code

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]

Message-ID: <20120529073417.GA25041@mail.gnudd.com>
Date:	Tue, 29 May 2012 09:34:17 +0200
From:	Alessandro Rubini <rubini@...dd.com>
To:	hpa@...or.com
Cc:	linux-kernel@...r.kernel.org, giancarlo.asnaghi@...com,
	alan@...ux.intel.com, tglx@...utronix.de, mingo@...hat.com,
	sameo@...ux.intel.com, x86@...nel.org
Subject: Re: [PATCH] x86/platform: sta2x11: add platform code

> I am not going to accept into the kernel a bunch of board-specific
> files.

Ok.

> PCI cards are different: they have PCI IDs, and they can be
> loaded, as modules, at runtime.  Furthermore, they tend to be very
> limited in the amount of variation:

Well, please check drivers/media/video/bt8xx: the "bttv-cards" file is
the biggest one. But I see your point.

> a single chip (represented PCI ID) may be slightly differently wired
> on different boards (represented by subsystem ID), but the variation
> tends to be limited; in the rare case it is not, there is usually
> some form of discovery mechanism.

Here the thing is 4 uart, 4 mmc, 3 spi, 128 gpio, 2 dma engines, usb,
sata, audio, ....  So some differences in wiring are there between
boards.  And no, no autodiscovery unfortunately (but we can use the
command line, so the driver knows who the installation is when it runs
its probe methods).

> Those are the *only* kinds conditions under which that kind of things,
> in drivers, is acceptable.  A list of mainboards and their wirings in C
> code?  No way in hell.

Ok. Although you can think of them as plug in boards.

>> I'm pretty sure we don't have ACPI, and I'd avoid device tree if
>> possible (especially thinking of add-on cards).  If you think it makes
>> more sense, I can offer the code to drivers/pci or other more generic
>> places.
> 
> What does "offer the code" mean here?  Just put the same sh*t in a
> different place?  No, no, no, no.

Yes, that was the suggestion :)

> We have the device tree mechanism as an escape valve for the systems
> built without any sane consideration for the platform, and that is the
> last resort.  I am generally not happy with that in the x86 space, even,
> because it means yet another failed platform, but it is still better
> than ad hoc hacks.

Unfortunately most vendors don't deal with autodetection, so the
number of "failed platforms" will increase, I fear. Especially
with increasing use of x86 in embedded contexts.

So, it seems I must go device-tree for the chipset-like mounting. And
what about plug in boards? I may arrange a firmware-loader mechanism
as an alternative, so the vendor of each board can provide the the
platform data for all the sub devices. Actually, if firmware loader is
acceptable, I'd try it first, to avoid changing the boot procedure;
maybe I can save myself from the device tree.

thanks
/alessandro
--
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/