SMC91x: forcing speed

SMC91x: forcing speed

[Martin Fuzzey]

Hi,

I am using the SMC91x driver on a based ARM board that has a hardware
problem causing 100Mbps mode not to work (even though the PHY
negotiates to that speed).
Unfortunately fixing the hardware is not an option :(

I'm currently using this simple hack to make it work:

diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c
index fdcbaf8..95f129e 100644
--- a/drivers/net/smc91x.c
+++ b/drivers/net/smc91x.c
@@ -2022,7 +2022,9 @@ static int __devinit smc_probe(struct net_device
*dev, void __iomem *ioaddr,

        if (lp->version >= (CHIP_91100 << 4)) {
                lp->ctl_rfduplx = 1;
+#ifndef CONFIG_MACH_PKN_TGX200
                lp->ctl_rspeed = 100;
+#endif
        }

        /* Grab the IRQ */

Is there a better way of doing this that would be acceptable for mainline?
The options I can think of are :

1) platform data : (new bit in flags or new member in struct smc91x_platdata)
2) command line parameter

I prefer 1) since that lets the board specific code do it rather than
messing with bootloader parameters.

I need NFS root so setting the speed later with miitool etc is not an
option [I don't want to add an initrd just for this]

I'm happy to submit the patch if we can agree on the method and other
people may be interested or should I just stick to my current hack?

Regards,

Martin

Re: SMC91x: forcing speed

[Richard Röjfors]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Fuzzey wrote:
> Hi,
> 
> Is there a better way of doing this that would be acceptable for mainline?

Look at include/linux/ethtool.h.

- --Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkon4gsACgkQ9yPqN8x056fEFQCgi2+3de3djG0JyjBJmSO1fiKa
lyYAn3hVMRxf75PcYNK0EFjx6fJE9YK/
=8fR/
-----END PGP SIGNATURE-----

Re: SMC91x: forcing speed

[Martin Fuzzey]

> Martin Fuzzey wrote:
>> Hi,
>>
>> Is there a better way of doing this that would be acceptable for mainline?
>
> Look at include/linux/ethtool.h.
>

Thank you for your reply.

The smc91x driver already has ethtool support.
However, as I stated in my original post, I don't want to use ethtool
from userspace since I need to be able to use a NFS rootfs.

So is there already a programmatic way of using the ethool interface
from the board specific setup code?
Or are you proposing adding a struct ethtool_cmd to smc91x_platdata ?

Another way I can think of is just to add a generic init() callback to
the platform data so that my board specific code can get at the
struct net_device * and then use the ethtool interface via dev->ethtool_ops.

Regards,

Martin

Re: SMC91x: forcing speed

[David Miller]

From: Martin Fuzzey <mfuzzey@gmail.com>
Date: Mon, 8 Jun 2009 14:02:05 +0200

> The smc91x driver already has ethtool support.
> However, as I stated in my original post, I don't want to use ethtool
> from userspace since I need to be able to use a NFS rootfs.

You can set the ethtool setting from an initramfs before the
NFS mount of the root filesystem occurs.

Re: SMC91x: forcing speed

[Martin Fuzzey]

David Miller wrote:
>> The smc91x driver already has ethtool support.
>> However, as I stated in my original post, I don't want to use ethtool
>> from userspace since I need to be able to use a NFS rootfs.
>>     
>
> You can set the ethtool setting from an initramfs before the
> NFS mount of the root filesystem occurs.
>   
Yes I sure could.
But I don't currently need a initramfs for anything else - adding one
would complicate the build and boot process.
IMHO the place for board specific hacks is in the board specifc startup
code - am I wrong?

Regards,

Martin

Re: SMC91x: forcing speed

[David Miller]

From: Martin Fuzzey <mfuzzey@gmail.com>
Date: Mon, 08 Jun 2009 23:42:47 +0200

> IMHO the place for board specific hacks is in the board specifc startup
> code - am I wrong?

We never add bootup time hacks for things that already have
a suitable generic and clean configuration interface.

People ask for module options and all kinds of crap like that
to set link parameters, and we always say no.

Re: SMC91x: forcing speed

[Nicolas Pitre]

On Mon, 8 Jun 2009, David Miller wrote:

> From: Martin Fuzzey <mfuzzey@gmail.com>
> Date: Mon, 08 Jun 2009 23:42:47 +0200
> 
> > IMHO the place for board specific hacks is in the board specifc startup
> > code - am I wrong?
> 
> We never add bootup time hacks for things that already have
> a suitable generic and clean configuration interface.

Maybe suitable in a workstation setup.

> People ask for module options and all kinds of crap like that
> to set link parameters, and we always say no.

And this is probably why there is still a disconnect between mainline 
and embedded people.

For some systems, the simple notion of a special ramdisk just makes the 
whole thing 4 times more complex.

Wouldn't it be possible to accommodate those people with a generic 
ethtool module that simply interpret some kernel cmdline parameters in a 
uniform and maintainable way to apply some settings during kernel boot?


Nicolas

Re: SMC91x: forcing speed

[David Miller]

From: Nicolas Pitre <nico@cam.org>
Date: Mon, 08 Jun 2009 18:17:21 -0400 (EDT)

> Wouldn't it be possible to accommodate those people with a generic 
> ethtool module that simply interpret some kernel cmdline parameters in a 
> uniform and maintainable way to apply some settings during kernel boot?

And you could even write it and maintain it somewhere if you
like for other embedded people to use. :-)

Once full featured, I'd be happy to include it.

Re: SMC91x: forcing speed

[Nicolas Pitre]

On Mon, 8 Jun 2009, David Miller wrote:

> From: Nicolas Pitre <nico@cam.org>
> Date: Mon, 08 Jun 2009 18:17:21 -0400 (EDT)
> 
> > Wouldn't it be possible to accommodate those people with a generic 
> > ethtool module that simply interpret some kernel cmdline parameters in a 
> > uniform and maintainable way to apply some settings during kernel boot?
> 
> And you could even write it and maintain it somewhere if you
> like for other embedded people to use. :-)
> 
> Once full featured, I'd be happy to include it.

I have no need for such a thing myself at the moment so I won't do it.

But at least you're open to the idea which is good, and now people with 
such a need have a hint.


Nicolas