linux-kernel - Re: [PATCH] ep93xx_eth.c: general cleanup

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] [day] [month] [year] [list]

Date:	Thu, 31 Dec 2009 10:11:22 +0100
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	H Hartley Sweeten <hartleys@...ionengravers.com>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, joe@...ches.com
Subject: Re: [PATCH] ep93xx_eth.c: general cleanup

On Wed, Dec 30, 2009 at 01:03:00PM -0500, H Hartley Sweeten wrote:

> >> Wednesday, December 16, 2009 11:32 AM, Lennert Buytenhek wrote:
> >>> On Wed, Dec 16, 2009 at 01:18:13PM -0500, H Hartley Sweeten wrote:
> >>>
> >>>> V3 - Change pr_fmt() as suggested by Joe Perches
> >>>>      Don't remove DRV_MODULE_NAME and DRV_MODULE_VERSION
> >>>>      Don't remove the message in ep93xx_eth_init_module()
> >>>
> >>> That's not what I meant, but alright, as you prefer.
> >> 
> >> Guess my parser is off line today.... ;-)
> >> 
> >> What did you mean?
> >
> > This patch also doesn't apply to current sources, so if you
> > could also please respin this once you've resolved the feedback
> > that would be great.
> 
> Lennert,

Hi Hartley,


> Since I need to respin this patch what did you mean by this comment?
> 
> On Wednesday, December 16, 2009 11:09 AM, Lennert Buytenhek wrote:
> > On Wed, Dec 16, 2009 at 01:06:10PM -0500, H Hartley Sweeten wrote:
> >
> >>>> General cleanup of the ep93xx_eth driver.
> >>>
> >>> Apart from keeping DRV_MODULE_NAME and DRV_MODULE_VERSION, I have
> >>> no strong opinion about this one way or the other.  So I guess that
> >>> means ACK.
> >> 
> >> I will add back the DRV_MODULE_NAME and DRV_MODULE_VERSION and repost.
> >> 
> >> What about the message in ep93xx_eth_init_module()?  Would you prefer
> >> that one to stay?
> >
> > Most drivers I'm familiar with print a version message when they are
> > first instantiated -- perhaps that makes more sense.
> 
> I will wait for your reply before updating the patch.

What I meant was, most drivers seem to print a message at probe
time, i.e. when they are attached to an actual device for the first
time.

Grepping for 'printed_version' in drivers/net/* actually turns up
two variants:
- Print the version message on the first probe.  (e.g. 3c59x)
- Print the version message at module load time if we were built as
  a module, while if we were built into the kernel, only print a
  version message on the first probe.  (e.g. 8139too)

At least in the case of ep93xx_eth, you can't even have it enabled if
you're not building a kernel specifically for the ep93xx ARM SoC, and
if you are building for the ep93xx, as far as I know we don't support
any boards that don't have the ethernet brought out and so you're very
likely to have ep93xx_eth enabled then, so whether you do it
unconditionally at driver init time or at probe time will make no
effective difference for the majority of cases.

I.e. I can't really say I care much either way.


cheers,
Lennert
--
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/