Message-Id: <1244744967.2785.61.camel@achroite>
Date:	Thu, 11 Jun 2009 19:29:27 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Nicolas Pitre <nico@....org>
Cc:	mfuzzey@...il.com, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] Ethtool style in kernel network driver
	configuration.

On Thu, 2009-06-11 at 13:44 -0400, Nicolas Pitre wrote:
> On Thu, 11 Jun 2009, Ben Hutchings wrote:
> 
> > On Thu, 2009-06-11 at 12:22 -0400, Nicolas Pitre wrote:
> > > On Thu, 11 Jun 2009, Ben Hutchings wrote:
> > > 
> > > > On Thu, 2009-06-11 at 08:47 +0200, Martin Fuzzey wrote:
> > > > > Ben Hutchings wrote:
> > > > > > Who needs this feature?  Why not use ethtool in an initramfs?
> > > > > >
> > > > > >   
> > > > > > Forcing speed and duplex is occasionally needed to work around a link
> > > > > > partner that doesn't implement autonegotiation correctly.  I don't see
> > > > > > that it should ever be needed in platform configuration.  If the driver
> > > > > > doesn't detect the MAC/PHY capabilities correctly then the driver should
> > > > > > be fixed.  Overriding the settings once will not prevent an unsupported
> > > > > > mode being selected later.
> > > > > >
> > > > > >   
> > > > > To summarize the recent points I made in the smc91x: forcing speed thread :
> > > > > 
> > > > > 1) Setting up and maintaining an initramfs can increase the complexity
> > > > > for embedded systems - it's another image file to build, distribute,
> > > > > update to bootloader etc.
> > > > 
> > > > This doesn't seem like a huge burden if you're net-booting.  And if
> > > > you're not net-booting, it's not critical that you override the link
> > > > mode immediately; you can do it in the regular init scripts.
> > > 
> > > Sure... But for some embedded setup this is actually more trouble and 
> > > hassle than having a non-intrusive kernel based facility that can set 
> > > defaults for you.
> > 
> > Doing it in an init script is even less intrusive!  But it seems that
> > the ethtool API doesn't do what you need in this case, anyway.
> 
> Stop thinking in terms of workstation setups please.

Maybe you should stop thinking that an embedded system has to do things
entirely differently?  Please note, I'm talking about an init script -
which you surely must have - not an initramfs, which I recognise is
optional and unnecessary for most embedded systems.

> [...]
> > It's an example of providing a generic solution, which is definitely
> > more than a quick hack, but I don't see it as a "clean solution" for the
> > problem that certain link modes don't work on a particular board.  A
> > clean solution would disable those modes altogether in the driver.
> 
> And now you are considering the addition of special restrictions for 
> some special hardware directly into the driver as less intrusive than 
> what is being proposed?  And now imagine what this would look like after 
> 56 different embedded designs have added their own kirks into the 
> driver.. because, yes, in the embedded world you do have much more than 
> 56 different designs sharing the same driver but each with their own 
> flaws.
[...]

I was thinking that you could add it to the platform data for such
devices, not that you would put board-specific quirks in the drivers.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists