[2.4 PATCH] arm: dma-arc add missing parenthesis

[2.4 PATCH] arm: dma-arc add missing parenthesis

[Mariusz Kozlowski]

Hello,

	This patch adds missing parenthesis in arc_floppy_data_enable_dma() code.

Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>

 arch/arm/kernel/dma-arc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -upr linux-2.4.34-pre6-a/arch/arm/kernel/dma-arc.c linux-2.4.34-pre6-b/arch/arm/kernel/dma-arc.c
--- linux-2.4.34-pre6-a/arch/arm/kernel/dma-arc.c	2003-08-25 13:44:39.000000000 +0200
+++ linux-2.4.34-pre6-b/arch/arm/kernel/dma-arc.c	2006-12-01 12:31:39.000000000 +0100
@@ -55,7 +55,7 @@ static void arc_floppy_data_enable_dma(d
 		memcpy ((void *)0x1c, (void *)&fdc1772_dma_write,
 			&fdc1772_dma_write_end - &fdc1772_dma_write);
 		fdc1772_setupdma(dma->buf.length, dma->buf.address); /* Sets data pointer up */
-		enable_fiq(FIQ_FLOPPYDATA;
+		enable_fiq(FIQ_FLOPPYDATA);
 
 		local_irq_restore(flags);
 	    }

-- 
Regards,

	Mariusz Kozlowski

Re: [2.4 PATCH] missing parenthesis

[Willy Tarreau]

Hi Mariusz,

Thanks for your work at fixing all this code. I'm wondering though,
given the type of errors, this code should never have been able to
build at all, so that means that it might not be used at all.

As a general rule of thumb, keep in mind that we're not much tempted
to fix known unused code, especially if it's unmaintained. The reason
is simple : when some code does not work, people who need it often
maintain patches in their tree to make it work. When we start changing
things there, their patches often apply with rejects. Anyway, *I* am
still for a clean kernel because I know that there's nothing more
annoying than spending days chasing a bug which we discover was known
for years.

So what I can propose you is that we :
  - postpone those patches for 2.4.35-pre
  - ask maintainers of each of these files if he accepts to fix the
    file, because some of them are totally against any such change.
  - we would merge the accepted patches and those without any reply
    which we consider relevant early in the 35-pre cycle so that
    people have some time to inform us about the potential conflicts
    they encounter.

Quite frankly, there should be very few problems, considering that we
have affected more files with the gcc4 patches and that nobody
complained.

As an exception, if you get some maintainer's approval for some of
the patches during 2.4.34 cycle, of course I will merge them first
because as I said, it's important to maintain supported code in good
shape.

Is it OK for you ?

Regards,
Willy

Re: [2.4 PATCH] missing parenthesis

[Mariusz Kozlowski]

Hi Willy, 

> Thanks for your work at fixing all this code. I'm wondering though,
> given the type of errors, this code should never have been able to
> build at all, so that means that it might not be used at all.

Either not used or #ifdef'ed so much that it is rarely build.

> As a general rule of thumb, keep in mind that we're not much tempted
> to fix known unused code, especially if it's unmaintained. The reason

Maybe dumb question but ... how do I know which parts of code are unused
and/or unmaintained?

> is simple : when some code does not work, people who need it often
> maintain patches in their tree to make it work. When we start changing
> things there, their patches often apply with rejects. Anyway, *I* am
> still for a clean kernel because I know that there's nothing more
> annoying than spending days chasing a bug which we discover was known
> for years.
> 
> So what I can propose you is that we :
>   - postpone those patches for 2.4.35-pre

Ok.

>   - ask maintainers of each of these files if he accepts to fix the
>     file, because some of them are totally against any such change.

Ok. Couple of questions:

- how do we do that?
- do I resend each patch to proper maintainer?
- if there is no maintainer then what? (btw. is there any other
more accurate source of MAINTAINERS for each file in the kernel tree?)
- do I have to resend them once more to LKML?

>   - we would merge the accepted patches and those without any reply
>     which we consider relevant early in the 35-pre cycle so that
>     people have some time to inform us about the potential conflicts
>     they encounter.
> 
> Quite frankly, there should be very few problems, considering that we
> have affected more files with the gcc4 patches and that nobody
> complained.
> 
> As an exception, if you get some maintainer's approval for some of
> the patches during 2.4.34 cycle, of course I will merge them first
> because as I said, it's important to maintain supported code in good
> shape.
> 
> Is it OK for you ?

Sure.

-- 
Regards,

	Mariusz Kozlowski

Re: [2.4 PATCH] missing parenthesis

[Willy Tarreau]

Hi Mariusz,

On Sat, Dec 02, 2006 at 12:00:24PM +0100, Mariusz Kozlowski wrote:
> Hi Willy, 
> 
> > Thanks for your work at fixing all this code. I'm wondering though,
> > given the type of errors, this code should never have been able to
> > build at all, so that means that it might not be used at all.
> 
> Either not used or #ifdef'ed so much that it is rarely build.

OK.

> > As a general rule of thumb, keep in mind that we're not much tempted
> > to fix known unused code, especially if it's unmaintained. The reason
> 
> Maybe dumb question but ... how do I know which parts of code are unused

- #if 0 (or equivalent), except #if DEBUG.
- obviously broken code which is included in files which compile and work
  for you

> and/or unmaintained?

just as I do : check for the maintainer in the files themselves, or in
the MAINTAINERS file. As a rule of thumb, if a file has not changed in
the last 3 years and its maintainer is not one of the active ones you
regularly see posting on LKML, then there are great chances that the
file is unmaintained. In this case, you might find the new maintainer
in the 2.6 port of the same file/driver. Same if the maintainer's
address bounces.

> > is simple : when some code does not work, people who need it often
> > maintain patches in their tree to make it work. When we start changing
> > things there, their patches often apply with rejects. Anyway, *I* am
> > still for a clean kernel because I know that there's nothing more
> > annoying than spending days chasing a bug which we discover was known
> > for years.
> > 
> > So what I can propose you is that we :
> >   - postpone those patches for 2.4.35-pre
> 
> Ok.
> 
> >   - ask maintainers of each of these files if he accepts to fix the
> >     file, because some of them are totally against any such change.
> 
> Ok. Couple of questions:
> 
> - how do we do that?

generally, the core subsystems (network, filesystems, archs, ...) are
still well maintained by people who *really want* to validate the
patches before forwarding them upstream.

> - do I resend each patch to proper maintainer?

Yes, when you can identify them without too much difficulty. For all
network drivers, please send to Jeff Garzik and netdev@vger.kernel.org.
For the rest of the network stuff, use Davem and netdev. Send to Al Viro
for FS. Davem for arch/sparc*, Russell King for arch/arm, Ralf Baechle
for arch/mips*, Paul Mackerras for arch/ppc*, etc... If you find a list
address in the MAINTAINERS file, please CC it too. They're all busy,
so make the question simple enough so that they can quickly reply with
ACK/NACK/QUEUED. Keep me CCed so that you don't have to forward me the
response. Generally, they will reply within one week.

It might seem a bit complicated and heavy, but it's the only way to
get a continued quality support on the whole code.

> - if there is no maintainer then what? (btw. is there any other
> more accurate source of MAINTAINERS for each file in the kernel tree?)

If there's no easily identifiable maintainer anymore, or if some
maintainers don't reply, then it becomes my job.

> - do I have to resend them once more to LKML?

No, not at all. We're not doing administrative and repetitive tasks,
and we can still dig through the list archives for a missing patch :-)
Don't waste your time doing this.

Thanks,
Willy