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: <alpine.LFD.1.00.0802202226000.2732@xanadu.home>
Date:	Wed, 20 Feb 2008 22:28:59 -0500 (EST)
From:	Nicolas Pitre <nico@....org>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	netdev@...r.kernel.org, lethal@...ux-sh.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 02/04] smc91x: introduce platform data flags

On Thu, 21 Feb 2008, Magnus Damm wrote:

> On Thu, Feb 21, 2008 at 12:58 AM, Nicolas Pitre <nico@....org> wrote:
> > On Wed, 20 Feb 2008, Magnus Damm wrote:
> >
> >  > This patch introduces struct smc91x_platdata and modifies the driver so
> >  > bus width is checked during run time using SMC_nBIT() instead of
> >  > SMC_CAN_USE_nBIT.
> >  >
> >  > Signed-off-by: Magnus Damm <damm@...l.co.jp>
> >  > ---
> >
> >  NAK.
> >
> >  The SMC91C111 (for example) is often used on devices which have a CPU
> >  clock barely higher than the network throughput, hence it is crutial for
> >  those devices to have the most efficient access possible to the chip or
> >  performance will suffer.  This is the main reason behind the heavily
> >  macroized register access so things are always optimized for the data
> >  bus capabilities at compile time.
> 
> I understand that you want to keep the code as fast as possible. So do
> I. But I want to remove the need to modify smc91x.h for each board I
> want to support. It is much better in my opinion to have a wide range
> of boards supported but a little bit lower throughput compared to only
> a few boards supported and excellent performance... People can always
> modify the header file by themselves if they want to squeeze out that
> extra percent of performance.

Sure.  That's perfectly fine for new boards.  But existing setups should 
not regress due to this change.

> >  I think you should add a SMC_DYNAMIC_BUS_CONFIG and redefine SMC_nBITS()
> >  so they dereference cfg.flags only when it is defined.
> 
> Sure, good idea. I'll fix that. Do you mind if I make that the default
> behavior? So boards that doesn't have any hard coded configuration in
> smc91x.h can use the platform data flags method for configuration
> instead.

Yes, that's fine.


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ