linux-kernel - Re: [RFC PATCH 2/2] mmc: add OpenFirmware bindings for the mmc

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: <be6dcc7a8a3132a40af7dfed9a430876@kernel.crashing.org>
Date:	Sun, 25 May 2008 01:14:28 +0200
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Jochen Friedrich <jochen@...am.de>
Cc:	linux-kernel@...r.kernel.org, Pierre Ossman <drzeus-mmc@...eus.cx>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Gary Jennejohn <garyj@...x.de>, linuxppc-dev@...abs.org,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [RFC PATCH 2/2] mmc: add OpenFirmware bindings for the mmc_spi driver

>> The real problem is we don't yet have good method (or place) to apply
>> a translation table from compatible values to modaliases.  Ideally,
>> the translations should be part of the drivers themselves, but that
>> causes a chicken and egg problem of needing to load the driver to get
>> access to the table to know if it is the correct driver... Of course,
>> I'm really not very familiar with the whole module autoloading
>> mechanism.  Regardless; binding should be based on compatible, not on
>> a hacky and bogus linux,modalias property.
>
> i2c exactly has the same problem. Here the compatible entry is used
> in drivers/of/of_i2c.c and mangled into a name to be used as modalias.
> It's still sort of hackish, but it seems to be a compromise acceptable
> by both OF and i2c folks.

It's perfectly acceptable.  The sole purpose of "compatible" is for
a client (i.e., the kernel) to decide what to do with this device;
most often, to decide what driver to use.

It would be nice to have a completely generic thing that matches device
tree nodes to drivers, and it sounds perfectly reasonable to me to go
via modalias for that (i.e., just translate from device tree namespace
to the kernel driver namespace).

As a bonus, it would make driver matching more correct in some places:
currently, whatever driver matches first wins (i.e., which "compatible"
value is tried first), but the ordering of different values in 
"compatible"
is supposed to be significant (whatever is mentioned there first should
win).

Segher

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