From rddunlap@xxxxxxxx Tue Aug 03 01:47:23 2004
...
On Mon, 02 Aug 2004 23:29:20 +1000 Bruce Janson wrote:
...
| On Sun, 01 Aug 2004 00:48:22 +1000 Bruce Janson wrote:
|
| | I have a linux 2.6.7 kernel which contains a compiled-in tulip
driver.
| | I would like to be able to boot the kernel with parameters that
| | will allow control of the tulip device. On some ethernet devices
| | this used to be possible via (something like):
| |
| | ether=0,0,1,0,eth0
| |
| | which would pass the four numeric parameters (as, I think, dev->irq,
| | dev->ioaddr, dev->mem_start and dev->mem_end) to the net driver that
| | controlled eth0. A convention adopted by some net drivers then
allowed
| | dev->mem_start to be interpretted as a set of flags that would
control
| | device characteristics (e.g. full-duplex vs half-duplex mode).
| | In .../linux-2.6.7/drivers/net/tulip/tulip_core.c:1587:
| |
| | if (dev->mem_start & MEDIA_MASK)
| | tp->default_port = dev->mem_start & MEDIA_MASK;
| |
| | suggests that this might still work. However, I have been unable
| | to force dev->mem_start in that driver to become non-zero via any
| | kernel boot-time parameters. My limited understanding of the code
| | that precedes the above lines in that file suggests that the "dev"
| | structure is not what it used to be...
|
| The driver never calls netdev_boot_setup_check(), which is
| what would give the driver its command line parameters.
|
| Did this work in early 2.6.x? There have been several changes
| in this area.
| ...
|
| No idea. This is the first in the 2.6 kernel series that I have
| tried.
|
| The driver can't do a simple call to netdev_boot_setup_check()
| because that will overwrite dev-> {irq, base_addr, mem_start,
mem_end},
| and those values come from PCI config space for PCI drivers.
| The driver could create a fake <dev> for that purpose, but it's
| more likely that ethtool or mii-tool should be used to change
| media/speed etc... Although now that I look at the driver source
| code, I don't see ethtool or mii-tool support for those options.
| ...
|
| Yes (tried that too :-().
Which/what have you tried?
...
By that I meant that I had tried to use ethtool to change
settings after boot and found that the tulip driver did
not support use of ethtool in that way. I have not tried
mii-tool (recently). However, neither of these are a
satisfactory solution as I need to have the interace come
up in the desired mode initially, not some time later.
| | ../linux-2.6.7/Documentation/kernel-parameters.txt:402 still
| | mentions "ether=..." but marks it as obsolete, replaced by
| | the equivalent "netdev=...". Elsewhere in that file, the entry
| | for "netdev=..." describes what appears to be the functionality
| | that I seek.
| |
| | So, is it still possible to perform the same sort of control
| | operations on a tulip driver via kernel boot-time parameters
| | as one can do via module load-time parameters? If so, how?
|
| The current tulip-core driver supports setting only the default
transceiver
| (media type) on the kernel boot/command line when the driver is built
into
| the kernel image (using mem_start, as you noted above).
| ...
|
| Sorry, I don't follow the above. Would you mind giving me an example,
| please, of how for the tulip driver I might set the default transceiver
| (media type) on the kernel boot/command line when the driver is built
| into the kernel image?
No, I can't. tulip-core uses <mem_start> to mean transceiver, but
like I said above, it never calls netdev_boot_setup_check() to get that
data, so it's useless currently. Sorry.
...
No need to apologise. All I wanted to hear was that
someone who actually understood the code agreed that
the tulip driver, this boot-time parameter setting
mechanism and the documentation (such as it is) are
currently mutually buggered :-). Now that I know that,
I can stop beating my head against the wall trying to
work out what I have done wrong and instead, get on
with working around this limitation. Many thanks! :-)
|