subject:"Re\: build #337 failed for 2.6.24\-rc1\-gb1d08ac In function `usbnet_set

On Wed, Nov 07, 2007 at 11:52:32PM +0100, Adrian Bunk wrote:
> On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
> > > > But on the other hand, it seems that only the ASIX code will work
> > > > right; the DM9601 and MCS7830 Kconfig is different/wrong.
> > > 
> > > I'm not seeing the problem.
> > > 
> > > Which configuration will be handled wrongly?
> > 
> > Notice how only the ASIX kconfig depended on NET_ETHERNET...
> > since MII depends on NET_ETHERNET, and (last I knew) the
> > reverse dependencies didn't capture the complete dependency
> > tree, selecting only MII would leave out some stuff.
> 
> Except for one s390 net driver (I'll check why it's doing this) the 
> NET_ETHERNET option does not influence what code is being generated - 
> it's just a Kconfig-internal option allowing to disable a huge bunch
> of drivers at once.

Damn, I shouldn't have only grep'ed under drivers/.

@davem:

Please look at net/ipv4/arp.c:arp_process()

Am I right that CONFIG_NET_ETHERNET=n and CONFIG_NETDEV_1000=y or 
CONFIG_NETDEV_1=y will not be handled correctly there?

And the best solution is to nuke all #ifdef's in this function and make 
the code unconditionally available?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wed, Nov 07, 2007 at 06:53:48PM -0800, David Brownell wrote:
> On Wednesday 07 November 2007, Adrian Bunk wrote:
> > On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
> > > > > But on the other hand, it seems that only the ASIX code will work
> > > > > right; the DM9601 and MCS7830 Kconfig is different/wrong.
> > > > 
> > > > I'm not seeing the problem.
> > > > 
> > > > Which configuration will be handled wrongly?
> > > 
> > > Notice how only the ASIX kconfig depended on NET_ETHERNET...
> > > since MII depends on NET_ETHERNET, and (last I knew) the
> > > reverse dependencies didn't capture the complete dependency
> > > tree, selecting only MII would leave out some stuff.
> > 
> > Except for one s390 net driver (I'll check why it's doing this) the 
> > NET_ETHERNET option does not influence what code is being generated - 
> > it's just a Kconfig-internal option allowing to disable a huge bunch
> > of drivers at once.
> 
> Drivers like ... AX88xxx, DM9601, and MCS7830!!  Except as
> it turns out, only the first one behaves as intended.
> 
> You can tell it's a problem by the way it's inconsistent,
> regardless of the details of the problem.  :)

I'm all for cleanups that make things consistent.  :)

As long as we can agree that there's a difference between a problem like 
a compile or runtime error and an opportunity for making things 
consistent.

> - Dave

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wednesday 07 November 2007, Adrian Bunk wrote:
> On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
> > > > But on the other hand, it seems that only the ASIX code will work
> > > > right; the DM9601 and MCS7830 Kconfig is different/wrong.
> > > 
> > > I'm not seeing the problem.
> > > 
> > > Which configuration will be handled wrongly?
> > 
> > Notice how only the ASIX kconfig depended on NET_ETHERNET...
> > since MII depends on NET_ETHERNET, and (last I knew) the
> > reverse dependencies didn't capture the complete dependency
> > tree, selecting only MII would leave out some stuff.
> 
> Except for one s390 net driver (I'll check why it's doing this) the 
> NET_ETHERNET option does not influence what code is being generated - 
> it's just a Kconfig-internal option allowing to disable a huge bunch
> of drivers at once.

Drivers like ... AX88xxx, DM9601, and MCS7830!!  Except as
it turns out, only the first one behaves as intended.

You can tell it's a problem by the way it's inconsistent,
regardless of the details of the problem.  :)

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
> > > But on the other hand, it seems that only the ASIX code will work
> > > right; the DM9601 and MCS7830 Kconfig is different/wrong.
> > 
> > I'm not seeing the problem.
> > 
> > Which configuration will be handled wrongly?
> 
> Notice how only the ASIX kconfig depended on NET_ETHERNET...
> since MII depends on NET_ETHERNET, and (last I knew) the
> reverse dependencies didn't capture the complete dependency
> tree, selecting only MII would leave out some stuff.

Except for one s390 net driver (I'll check why it's doing this) the 
NET_ETHERNET option does not influence what code is being generated - 
it's just a Kconfig-internal option allowing to disable a huge bunch
of drivers at once.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

> > But on the other hand, it seems that only the ASIX code will work
> > right; the DM9601 and MCS7830 Kconfig is different/wrong.
> 
> I'm not seeing the problem.
> 
> Which configuration will be handled wrongly?

Notice how only the ASIX kconfig depended on NET_ETHERNET...
since MII depends on NET_ETHERNET, and (last I knew) the
reverse dependencies didn't capture the complete dependency
tree, selecting only MII would leave out some stuff.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wednesday 07 November 2007, David Miller wrote:
> David, I hate to say this and point you out like this, but you are a
> real cancer for bug fixes to USB things in the kernel,

You didn't hate it enough to find a way to deal with your issue
that doesn't involve namecalling or other flamage, I'll note.

I know, I know ... you wouldn't want anyone to get the mistaken
impression that LKML is one of those easy-to-get-along-on mailing
lists.  Namecalling helps prevent anyone from ever thinking that!

> If I had a nickel for every patch from someone else you grinded into
> the ground and stalled I'd truly be a millionare.

Hyperbole helps too...

Twenty million patches, surely from some large fraction of a
million kernel patch submitters ... what a crazy dream!
(An enviable one, maybe; but way below the last statistics
on the subject which I read.)

As for "grind into the ground and stall" ... clearly that's
not how I'd describe things.

> You absolutely stifle development progress.  I thought my OHCI
> deadlock patch was an isolated case (and nothing is still applied,
> which is just awesome, my original patch was posted more than a month
> ago),

I'm not sure why the patch I signed off on didn't merge either;
that was specificially related to the OHCI part of that problem.

Hmm, digging through my mail I see several other patches doing
the same thing were also floating around.  None of them had any
improvement over what I had signed off on.  Maybe there was just
too much confusion for Greg to want to merge the one which I'd
already signed off on...

It hasn't been removed from my merge queue, since it's not yet
shown up from kernel.org ... which means that it'd be one of
the patches to be resubmitted before we get much deeper into
this particular RC series.  In fact, I just resent it (with a
few minor tweaks, essentially comment updates).

Of course, *YOU* are the roadblock on the more generic side of
that problem.  I don't recall hearing back from you about the
minor/obvious update to the HUB+EHCI patch adding a msleep()
to bypass the hardware race you reported.

That is, other than your refusal to even try letting the three
or more clock domains finish synchronizing, before releasing
that lock and then starting something that relied on that synch
having finished...

>   but you're doing the same exact thing to Adrian here too.

Hmm, and there I was prepared to sign off on Adrian's last patch.
True, I hadn't yet done so.  But there were several workable fixes
in hand, plus a trivial workaround ... I just didn't make time to
try that one out over the weekend.

I'm glad you grabbed the patch I would have signed off on, if I'd
had time to verify it.

> You want to see things fixed your way.  But you can get away with the
> if, and only if, you can spend every day working on your own version
> of fixes when you don't like the submitters version.

You know, that's hardly a standard kernel-wide policy for how
maintainers work ... except maybe ones in "supported" areas,
and not always even then.

Though I certainly know why it could seem attactive to want that
treatment for patches you submit. I know many of us would just love
to get that level of response/support for everything we submit.
I don't always get it; in some areas, it *never* happens.

In fact, it's pretty routine to have patches wait for a while
before they get merged, or even sometimes reviewed ... where
"a while" will sometimes cover many (annoying) months.

Also, some maintainers demand many iterations of patches, without
doing *any* fixup themselves.  It's as if ... hmm ... maybe there
were only so many hours per day going into that such stuff?  Or as
if people had different priorities?  Bizarre notions, I know!!

>   But unlike me
> you don't have that luxury so you have to give patch submitters a
> larger level of freedom and, plainly, just "let go".

Same goes for maintainers too, you know.  If you're still
wondering about a patch, a private "ping" is common practice;
far more so than public vilification.

In fact, it's best if you never use a public vilification step.
Certainly not until after conventional measures ("ping!") fail
repeatedly, and bad faith has been clearly shown.  (Neither of
which apply in this case.)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

2007-11-07 Thread David Miller


David, I hate to say this and point you out like this, but you are a
real cancer for bug fixes to USB things in the kernel, and I'm very
tired of seeing things stuck in the mud (and engineering resources
wasted) because of how you handle things.  It's very bad for Linux,
and the USB code in particular.

If I had a nickel for every patch from someone else you grinded into
the ground and stalled I'd truly be a millionare.

You absolutely stifle development progress.  I thought my OHCI
deadlock patch was an isolated case (and nothing is still applied,
which is just awesome, my original patch was posted more than a month
ago), but you're doing the same exact thing to Adrian here too.

You want to see things fixed your way.  But you can get away with the
if, and only if, you can spend every day working on your own version
of fixes when you don't like the submitters version.  But unlike me
you don't have that luxury so you have to give patch submitters a
larger level of freedom and, plainly, just "let go".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

2007-11-07 Thread David Miller


David, I hate to say this and point you out like this, but you are a
real cancer for bug fixes to USB things in the kernel, and I'm very
tired of seeing things stuck in the mud (and engineering resources
wasted) because of how you handle things.  It's very bad for Linux,
and the USB code in particular.

If I had a nickel for every patch from someone else you grinded into
the ground and stalled I'd truly be a millionare.

You absolutely stifle development progress.  I thought my OHCI
deadlock patch was an isolated case (and nothing is still applied,
which is just awesome, my original patch was posted more than a month
ago), but you're doing the same exact thing to Adrian here too.

You want to see things fixed your way.  But you can get away with the
if, and only if, you can spend every day working on your own version
of fixes when you don't like the submitters version.  But unlike me
you don't have that luxury so you have to give patch submitters a
larger level of freedom and, plainly, just let go.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wednesday 07 November 2007, David Miller wrote:
 David, I hate to say this and point you out like this, but you are a
 real cancer for bug fixes to USB things in the kernel,

You didn't hate it enough to find a way to deal with your issue
that doesn't involve namecalling or other flamage, I'll note.

I know, I know ... you wouldn't want anyone to get the mistaken
impression that LKML is one of those easy-to-get-along-on mailing
lists.  Namecalling helps prevent anyone from ever thinking that!


 If I had a nickel for every patch from someone else you grinded into
 the ground and stalled I'd truly be a millionare.

Hyperbole helps too...

Twenty million patches, surely from some large fraction of a
million kernel patch submitters ... what a crazy dream!
(An enviable one, maybe; but way below the last statistics
on the subject which I read.)

As for grind into the ground and stall ... clearly that's
not how I'd describe things.


 You absolutely stifle development progress.  I thought my OHCI
 deadlock patch was an isolated case (and nothing is still applied,
 which is just awesome, my original patch was posted more than a month
 ago),

I'm not sure why the patch I signed off on didn't merge either;
that was specificially related to the OHCI part of that problem.

Hmm, digging through my mail I see several other patches doing
the same thing were also floating around.  None of them had any
improvement over what I had signed off on.  Maybe there was just
too much confusion for Greg to want to merge the one which I'd
already signed off on...


It hasn't been removed from my merge queue, since it's not yet
shown up from kernel.org ... which means that it'd be one of
the patches to be resubmitted before we get much deeper into
this particular RC series.  In fact, I just resent it (with a
few minor tweaks, essentially comment updates).


Of course, *YOU* are the roadblock on the more generic side of
that problem.  I don't recall hearing back from you about the
minor/obvious update to the HUB+EHCI patch adding a msleep()
to bypass the hardware race you reported.

That is, other than your refusal to even try letting the three
or more clock domains finish synchronizing, before releasing
that lock and then starting something that relied on that synch
having finished...


   but you're doing the same exact thing to Adrian here too.

Hmm, and there I was prepared to sign off on Adrian's last patch.
True, I hadn't yet done so.  But there were several workable fixes
in hand, plus a trivial workaround ... I just didn't make time to
try that one out over the weekend.

I'm glad you grabbed the patch I would have signed off on, if I'd
had time to verify it.


 You want to see things fixed your way.  But you can get away with the
 if, and only if, you can spend every day working on your own version
 of fixes when you don't like the submitters version.

You know, that's hardly a standard kernel-wide policy for how
maintainers work ... except maybe ones in supported areas,
and not always even then.

Though I certainly know why it could seem attactive to want that
treatment for patches you submit. I know many of us would just love
to get that level of response/support for everything we submit.
I don't always get it; in some areas, it *never* happens.

In fact, it's pretty routine to have patches wait for a while
before they get merged, or even sometimes reviewed ... where
a while will sometimes cover many (annoying) months.


Also, some maintainers demand many iterations of patches, without
doing *any* fixup themselves.  It's as if ... hmm ... maybe there
were only so many hours per day going into that such stuff?  Or as
if people had different priorities?  Bizarre notions, I know!!


   But unlike me
 you don't have that luxury so you have to give patch submitters a
 larger level of freedom and, plainly, just let go.

Same goes for maintainers too, you know.  If you're still
wondering about a patch, a private ping is common practice;
far more so than public vilification.

In fact, it's best if you never use a public vilification step.
Certainly not until after conventional measures (ping!) fail
repeatedly, and bad faith has been clearly shown.  (Neither of
which apply in this case.)


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

  But on the other hand, it seems that only the ASIX code will work
  right; the DM9601 and MCS7830 Kconfig is different/wrong.
 
 I'm not seeing the problem.
 
 Which configuration will be handled wrongly?

Notice how only the ASIX kconfig depended on NET_ETHERNET...
since MII depends on NET_ETHERNET, and (last I knew) the
reverse dependencies didn't capture the complete dependency
tree, selecting only MII would leave out some stuff.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wed, Nov 07, 2007 at 06:53:48PM -0800, David Brownell wrote:
 On Wednesday 07 November 2007, Adrian Bunk wrote:
  On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
 But on the other hand, it seems that only the ASIX code will work
 right; the DM9601 and MCS7830 Kconfig is different/wrong.

I'm not seeing the problem.

Which configuration will be handled wrongly?
   
   Notice how only the ASIX kconfig depended on NET_ETHERNET...
   since MII depends on NET_ETHERNET, and (last I knew) the
   reverse dependencies didn't capture the complete dependency
   tree, selecting only MII would leave out some stuff.
  
  Except for one s390 net driver (I'll check why it's doing this) the 
  NET_ETHERNET option does not influence what code is being generated - 
  it's just a Kconfig-internal option allowing to disable a huge bunch
  of drivers at once.
 
 Drivers like ... AX88xxx, DM9601, and MCS7830!!  Except as
 it turns out, only the first one behaves as intended.
 
 You can tell it's a problem by the way it's inconsistent,
 regardless of the details of the problem.  :)

I'm all for cleanups that make things consistent.  :)

As long as we can agree that there's a difference between a problem like 
a compile or runtime error and an opportunity for making things 
consistent.

 - Dave

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wed, Nov 07, 2007 at 11:52:32PM +0100, Adrian Bunk wrote:
 On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
But on the other hand, it seems that only the ASIX code will work
right; the DM9601 and MCS7830 Kconfig is different/wrong.
   
   I'm not seeing the problem.
   
   Which configuration will be handled wrongly?
  
  Notice how only the ASIX kconfig depended on NET_ETHERNET...
  since MII depends on NET_ETHERNET, and (last I knew) the
  reverse dependencies didn't capture the complete dependency
  tree, selecting only MII would leave out some stuff.
 
 Except for one s390 net driver (I'll check why it's doing this) the 
 NET_ETHERNET option does not influence what code is being generated - 
 it's just a Kconfig-internal option allowing to disable a huge bunch
 of drivers at once.

Damn, I shouldn't have only grep'ed under drivers/.

@davem:

Please look at net/ipv4/arp.c:arp_process()

Am I right that CONFIG_NET_ETHERNET=n and CONFIG_NETDEV_1000=y or 
CONFIG_NETDEV_1=y will not be handled correctly there?

And the best solution is to nuke all #ifdef's in this function and make 
the code unconditionally available?

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wednesday 07 November 2007, Adrian Bunk wrote:
 On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
But on the other hand, it seems that only the ASIX code will work
right; the DM9601 and MCS7830 Kconfig is different/wrong.
   
   I'm not seeing the problem.
   
   Which configuration will be handled wrongly?
  
  Notice how only the ASIX kconfig depended on NET_ETHERNET...
  since MII depends on NET_ETHERNET, and (last I knew) the
  reverse dependencies didn't capture the complete dependency
  tree, selecting only MII would leave out some stuff.
 
 Except for one s390 net driver (I'll check why it's doing this) the 
 NET_ETHERNET option does not influence what code is being generated - 
 it's just a Kconfig-internal option allowing to disable a huge bunch
 of drivers at once.

Drivers like ... AX88xxx, DM9601, and MCS7830!!  Except as
it turns out, only the first one behaves as intended.

You can tell it's a problem by the way it's inconsistent,
regardless of the details of the problem.  :)

- Dave
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
   But on the other hand, it seems that only the ASIX code will work
   right; the DM9601 and MCS7830 Kconfig is different/wrong.
  
  I'm not seeing the problem.
  
  Which configuration will be handled wrongly?
 
 Notice how only the ASIX kconfig depended on NET_ETHERNET...
 since MII depends on NET_ETHERNET, and (last I knew) the
 reverse dependencies didn't capture the complete dependency
 tree, selecting only MII would leave out some stuff.

Except for one s390 net driver (I'll check why it's doing this) the 
NET_ETHERNET option does not influence what code is being generated - 
it's just a Kconfig-internal option allowing to disable a huge bunch
of drivers at once.

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Fri, Nov 02, 2007 at 11:45:15AM -0700, David Brownell wrote:
>...
> --- a.orig/drivers/net/usb/usbnet.c   2007-10-13 15:16:10.0 -0700
> +++ a/drivers/net/usb/usbnet.c2007-11-02 11:39:59.0 -0700
> @@ -682,10 +682,17 @@ done_nopm:
>  /* ethtool methods; minidrivers may need to add some more, but
>   * they'll probably want to use this base set.
>   */
> +#undef HAVE_MII
>  
> -#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
> +#if defined(CONFIG_MII)
>  #define HAVE_MII
>  
> +#elif defined(CONFIG_MII_MODULE) && defined(MODULE)
> +#define HAVE_MII
> +#endif
> +
> +#ifdef HAVE_MII
> +
>  int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
>  {
>   struct usbnet *dev = netdev_priv(net);
> 

Despite all what you do in Kconfig and what you wrongly blame on 
"select" the bug is in usbnet.c and this fix to usbnet.c _alone_  
would be enough to fix the bug.

But since you said you care about not including bloat you should better 
take my second patch that results in smaller code in some configurations.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Fri, Nov 02, 2007 at 12:30:22PM -0700, David Brownell wrote:
> On Friday 02 November 2007, Adrian Bunk wrote:
> > This approach has two disadvantages:
> > - it's complicated
> 
> No more so than the problem itself.
> 
> 
> > - the MII stuff is an implementation detail, and we shouldn't bother
> >   the user with it (especially since we can do better)
> 
> That's a Kconfig policy that's not always followed.

Sure it's not yet always followed.

But kernel developers have to become more aware that the vast majority 
of kconfig users are not kernel hackers and act accordingly.

I'm not talking about the infamous Aunt Tillie, but being able to 
build your own kernel is even required for LPIC-1. [1]

> In this
> case, I was getting fed up with "select".  It so rarely does
> what it needs to do, and I've started to think it'd be better
> to just always avoid that fragility than battle it.

Regarding this bug, "select" is completely innocent...

> > If you want to keep the #ifdef's, what's the problem with the second 
> > patch I proposed to fix this bug?
> 
> For one thing, I didn't see it until after I posted this one...
> other than that, the basic approach could well be fine; I didn't
> go through it in detail.
> 
> But on the other hand, it seems that only the ASIX code will work
> right; the DM9601 and MCS7830 Kconfig is different/wrong.

I'm not seeing the problem.

Which configuration will be handled wrongly?

> - Dave

cu
Adrian

[1] 
http://www.lpi.org/en/lpi/english/certification/the_lpic_program/exam_102_detailed_objectives

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Friday 02 November 2007, Adrian Bunk wrote:
> This approach has two disadvantages:
> - it's complicated

No more so than the problem itself.

> - the MII stuff is an implementation detail, and we shouldn't bother
>   the user with it (especially since we can do better)

That's a Kconfig policy that's not always followed.  In this
case, I was getting fed up with "select".  It so rarely does
what it needs to do, and I've started to think it'd be better
to just always avoid that fragility than battle it.

> If you want to keep the #ifdef's, what's the problem with the second 
> patch I proposed to fix this bug?

For one thing, I didn't see it until after I posted this one...
other than that, the basic approach could well be fine; I didn't
go through it in detail.

But on the other hand, it seems that only the ASIX code will work
right; the DM9601 and MCS7830 Kconfig is different/wrong.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Fri, Nov 02, 2007 at 11:45:15AM -0700, David Brownell wrote:
> On Thursday 01 November 2007, Adrian Bunk wrote:
> > The following combination of options is simply an unusual one:
> > 
> > CONFIG_MII=m
> > CONFIG_USB_USBNET=y
> > CONFIG_USB_USBNET_MII=n
> 
> I though that had been fixed for ages ...
> 
> This should do a better job of it.
> 
> - Dave
> 
> ==CUT HERE
> Simplify handling of the MII-dependent usbnet based adapters:  stick
> to forward dependencies, and explicitly handle the core dependency.
> 
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> ---
>  drivers/net/usb/Kconfig  |   23 ---
>  drivers/net/usb/usbnet.c |9 -
>  2 files changed, 20 insertions(+), 12 deletions(-)
> 
> --- a.orig/drivers/net/usb/Kconfig2007-10-21 10:35:16.0 -0700
> +++ a/drivers/net/usb/Kconfig 2007-11-02 11:32:15.0 -0700
> @@ -93,13 +93,8 @@ config USB_RTL8150
> To compile this driver as a module, choose M here: the
> module will be called rtl8150.
>  
> -config USB_USBNET_MII
> - tristate
> - default n
> -
>  config USB_USBNET
>   tristate "Multi-purpose USB Networking Framework"
> - select MII if USB_USBNET_MII != n
>   ---help---
> This driver supports several kinds of network links over USB,
> with "minidrivers" built around a common network driver core
> @@ -131,11 +126,19 @@ config USB_USBNET
> To compile this driver as a module, choose M here: the
> module will be called usbnet.
>  
> +# usbnet core will support MII when MII is static, or both are modules
> +config USB_NET_MII
> + tristate
> + depends on USB_USBNET && NET_ETHERNET && (MII = y || MII = USB_USBNET)
> + default MII
> +
> +comment "MII support is needed for most Ethernet adapters"
> + depends on USB_USBNET && USB_NET_MII=n
>...

This approach has two disadvantages:
- it's complicated
- the MII stuff is an implementation detail, and we shouldn't bother
  the user with it (especially since we can do better)

If you want to keep the #ifdef's, what's the problem with the second 
patch I proposed to fix this bug?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Thursday 01 November 2007, Adrian Bunk wrote:
> The following combination of options is simply an unusual one:
> 
> CONFIG_MII=m
> CONFIG_USB_USBNET=y
> CONFIG_USB_USBNET_MII=n

I though that had been fixed for ages ...

This should do a better job of it.

- Dave

==  CUT HERE
Simplify handling of the MII-dependent usbnet based adapters:  stick
to forward dependencies, and explicitly handle the core dependency.

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
 drivers/net/usb/Kconfig  |   23 ---
 drivers/net/usb/usbnet.c |9 -
 2 files changed, 20 insertions(+), 12 deletions(-)

--- a.orig/drivers/net/usb/Kconfig  2007-10-21 10:35:16.0 -0700
+++ a/drivers/net/usb/Kconfig   2007-11-02 11:32:15.0 -0700
@@ -93,13 +93,8 @@ config USB_RTL8150
  To compile this driver as a module, choose M here: the
  module will be called rtl8150.
 
-config USB_USBNET_MII
-   tristate
-   default n
-
 config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
-   select MII if USB_USBNET_MII != n
---help---
  This driver supports several kinds of network links over USB,
  with "minidrivers" built around a common network driver core
@@ -131,11 +126,19 @@ config USB_USBNET
  To compile this driver as a module, choose M here: the
  module will be called usbnet.
 
+# usbnet core will support MII when MII is static, or both are modules
+config USB_NET_MII
+   tristate
+   depends on USB_USBNET && NET_ETHERNET && (MII = y || MII = USB_USBNET)
+   default MII
+
+comment "MII support is needed for most Ethernet adapters"
+   depends on USB_USBNET && USB_NET_MII=n
+
 config USB_NET_AX8817X
tristate "ASIX AX88xxx Based USB 2.0 Ethernet Adapters"
-   depends on USB_USBNET && NET_ETHERNET
+   depends on USB_USBNET && USB_NET_MII
select CRC32
-   select USB_USBNET_MII
default y
help
  This option adds support for ASIX AX88xxx based USB 2.0
@@ -188,9 +191,8 @@ config USB_NET_CDCETHER
 
 config USB_NET_DM9601
tristate "Davicom DM9601 based USB 1.1 10/100 ethernet devices"
-   depends on USB_USBNET
+   depends on USB_USBNET && USB_NET_MII
select CRC32
-   select USB_USBNET_MII
help
  This option adds support for Davicom DM9601 based USB 1.1
  10/100 Ethernet adapters.
@@ -224,8 +226,7 @@ config USB_NET_PLUSB
 
 config USB_NET_MCS7830
tristate "MosChip MCS7830 based Ethernet adapters"
-   depends on USB_USBNET
-   select USB_USBNET_MII
+   depends on USB_USBNET && USB_NET_MII
help
  Choose this option if you're using a 10/100 Ethernet USB2
  adapter based on the MosChip 7830 controller. This includes
--- a.orig/drivers/net/usb/usbnet.c 2007-10-13 15:16:10.0 -0700
+++ a/drivers/net/usb/usbnet.c  2007-11-02 11:39:59.0 -0700
@@ -682,10 +682,17 @@ done_nopm:
 /* ethtool methods; minidrivers may need to add some more, but
  * they'll probably want to use this base set.
  */
+#undef HAVE_MII
 
-#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
+#if defined(CONFIG_MII)
 #define HAVE_MII
 
+#elif defined(CONFIG_MII_MODULE) && defined(MODULE)
+#define HAVE_MII
+#endif
+
+#ifdef HAVE_MII
+
 int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
 {
struct usbnet *dev = netdev_priv(net);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Fri, Nov 02, 2007 at 11:45:15AM -0700, David Brownell wrote:
 On Thursday 01 November 2007, Adrian Bunk wrote:
  The following combination of options is simply an unusual one:
  
  CONFIG_MII=m
  CONFIG_USB_USBNET=y
  CONFIG_USB_USBNET_MII=n
 
 I though that had been fixed for ages ...
 
 This should do a better job of it.
 
 - Dave
 
 ==CUT HERE
 Simplify handling of the MII-dependent usbnet based adapters:  stick
 to forward dependencies, and explicitly handle the core dependency.
 
 Signed-off-by: David Brownell [EMAIL PROTECTED]
 ---
  drivers/net/usb/Kconfig  |   23 ---
  drivers/net/usb/usbnet.c |9 -
  2 files changed, 20 insertions(+), 12 deletions(-)
 
 --- a.orig/drivers/net/usb/Kconfig2007-10-21 10:35:16.0 -0700
 +++ a/drivers/net/usb/Kconfig 2007-11-02 11:32:15.0 -0700
 @@ -93,13 +93,8 @@ config USB_RTL8150
 To compile this driver as a module, choose M here: the
 module will be called rtl8150.
  
 -config USB_USBNET_MII
 - tristate
 - default n
 -
  config USB_USBNET
   tristate Multi-purpose USB Networking Framework
 - select MII if USB_USBNET_MII != n
   ---help---
 This driver supports several kinds of network links over USB,
 with minidrivers built around a common network driver core
 @@ -131,11 +126,19 @@ config USB_USBNET
 To compile this driver as a module, choose M here: the
 module will be called usbnet.
  
 +# usbnet core will support MII when MII is static, or both are modules
 +config USB_NET_MII
 + tristate
 + depends on USB_USBNET  NET_ETHERNET  (MII = y || MII = USB_USBNET)
 + default MII
 +
 +comment MII support is needed for most Ethernet adapters
 + depends on USB_USBNET  USB_NET_MII=n
...

This approach has two disadvantages:
- it's complicated
- the MII stuff is an implementation detail, and we shouldn't bother
  the user with it (especially since we can do better)

If you want to keep the #ifdef's, what's the problem with the second 
patch I proposed to fix this bug?

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Thursday 01 November 2007, Adrian Bunk wrote:
 The following combination of options is simply an unusual one:
 
 CONFIG_MII=m
 CONFIG_USB_USBNET=y
 CONFIG_USB_USBNET_MII=n

I though that had been fixed for ages ...

This should do a better job of it.

- Dave

==  CUT HERE
Simplify handling of the MII-dependent usbnet based adapters:  stick
to forward dependencies, and explicitly handle the core dependency.

Signed-off-by: David Brownell [EMAIL PROTECTED]
---
 drivers/net/usb/Kconfig  |   23 ---
 drivers/net/usb/usbnet.c |9 -
 2 files changed, 20 insertions(+), 12 deletions(-)

--- a.orig/drivers/net/usb/Kconfig  2007-10-21 10:35:16.0 -0700
+++ a/drivers/net/usb/Kconfig   2007-11-02 11:32:15.0 -0700
@@ -93,13 +93,8 @@ config USB_RTL8150
  To compile this driver as a module, choose M here: the
  module will be called rtl8150.
 
-config USB_USBNET_MII
-   tristate
-   default n
-
 config USB_USBNET
tristate Multi-purpose USB Networking Framework
-   select MII if USB_USBNET_MII != n
---help---
  This driver supports several kinds of network links over USB,
  with minidrivers built around a common network driver core
@@ -131,11 +126,19 @@ config USB_USBNET
  To compile this driver as a module, choose M here: the
  module will be called usbnet.
 
+# usbnet core will support MII when MII is static, or both are modules
+config USB_NET_MII
+   tristate
+   depends on USB_USBNET  NET_ETHERNET  (MII = y || MII = USB_USBNET)
+   default MII
+
+comment MII support is needed for most Ethernet adapters
+   depends on USB_USBNET  USB_NET_MII=n
+
 config USB_NET_AX8817X
tristate ASIX AX88xxx Based USB 2.0 Ethernet Adapters
-   depends on USB_USBNET  NET_ETHERNET
+   depends on USB_USBNET  USB_NET_MII
select CRC32
-   select USB_USBNET_MII
default y
help
  This option adds support for ASIX AX88xxx based USB 2.0
@@ -188,9 +191,8 @@ config USB_NET_CDCETHER
 
 config USB_NET_DM9601
tristate Davicom DM9601 based USB 1.1 10/100 ethernet devices
-   depends on USB_USBNET
+   depends on USB_USBNET  USB_NET_MII
select CRC32
-   select USB_USBNET_MII
help
  This option adds support for Davicom DM9601 based USB 1.1
  10/100 Ethernet adapters.
@@ -224,8 +226,7 @@ config USB_NET_PLUSB
 
 config USB_NET_MCS7830
tristate MosChip MCS7830 based Ethernet adapters
-   depends on USB_USBNET
-   select USB_USBNET_MII
+   depends on USB_USBNET  USB_NET_MII
help
  Choose this option if you're using a 10/100 Ethernet USB2
  adapter based on the MosChip 7830 controller. This includes
--- a.orig/drivers/net/usb/usbnet.c 2007-10-13 15:16:10.0 -0700
+++ a/drivers/net/usb/usbnet.c  2007-11-02 11:39:59.0 -0700
@@ -682,10 +682,17 @@ done_nopm:
 /* ethtool methods; minidrivers may need to add some more, but
  * they'll probably want to use this base set.
  */
+#undef HAVE_MII
 
-#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
+#if defined(CONFIG_MII)
 #define HAVE_MII
 
+#elif defined(CONFIG_MII_MODULE)  defined(MODULE)
+#define HAVE_MII
+#endif
+
+#ifdef HAVE_MII
+
 int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
 {
struct usbnet *dev = netdev_priv(net);

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Friday 02 November 2007, Adrian Bunk wrote:
 This approach has two disadvantages:
 - it's complicated

No more so than the problem itself.


 - the MII stuff is an implementation detail, and we shouldn't bother
   the user with it (especially since we can do better)

That's a Kconfig policy that's not always followed.  In this
case, I was getting fed up with select.  It so rarely does
what it needs to do, and I've started to think it'd be better
to just always avoid that fragility than battle it.

 
 If you want to keep the #ifdef's, what's the problem with the second 
 patch I proposed to fix this bug?

For one thing, I didn't see it until after I posted this one...
other than that, the basic approach could well be fine; I didn't
go through it in detail.

But on the other hand, it seems that only the ASIX code will work
right; the DM9601 and MCS7830 Kconfig is different/wrong.

- Dave


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

On Fri, Nov 02, 2007 at 12:30:22PM -0700, David Brownell wrote:
On Friday 02 November 2007, Adrian Bunk wrote:
This approach has two disadvantages:
- it's complicated

No more so than the problem itself.

- the MII stuff is an implementation detail, and we shouldn't bother
the user with it (especially since we can do better)

That's a Kconfig policy that's not always followed.

Sure it's not yet always followed.

But kernel developers have to become more aware that the vast majority
of kconfig users are not kernel hackers and act accordingly.

I'm not talking about the infamous Aunt Tillie, but being able to
build your own kernel is even required for LPIC-1. [1]

In this
case, I was getting fed up with select. It so rarely does
what it needs to do, and I've started to think it'd be better
to just always avoid that fragility than battle it.

Regarding this bug, select is completely innocent...

If you want to keep the #ifdef's, what's the problem with the second
patch I proposed to fix this bug?

For one thing, I didn't see it until after I posted this one...
other than that, the basic approach could well be fine; I didn't
go through it in detail.

But on the other hand, it seems that only the ASIX code will work
right; the DM9601 and MCS7830 Kconfig is different/wrong.

I'm not seeing the problem.

Which configuration will be handled wrongly?

- Dave

cu
Adrian

[1]
http://www.lpi.org/en/lpi/english/certification/the_lpic_program/exam_102_detailed_objectives

Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':