Re: [patch RESEND] atp870u: 64 bit bug in atp885_init()

2015-12-09 Thread One Thousand Gnomes
> You should just delete that code along with the Kconfig and Makefile > entries. Don't bother moving it to staging. The move to staging is > supposed to give people one last chance to yell if they absolutely need > the code. No one has compiled this code for years so no one will miss > it. And

Re: [patch RESEND] atp870u: 64 bit bug in atp885_init()

2015-12-09 Thread Dan Carpenter
On Wed, Dec 09, 2015 at 07:11:15PM +0100, Julia Lawall wrote: > Forgive my ignorance, but what is the exact procedure? For example, the > following file: drivers/pcmcia/vrc4173_cardu.c contains the following > code: INIT_WORK(&socket->tq_work, cardu_bh, socket);. The last time > INIT_WORK took th

Re: [patch RESEND] atp870u: 64 bit bug in atp885_init()

2015-12-09 Thread Julia Lawall
On Wed, 9 Dec 2015, Dan Carpenter wrote: > We should add a tag to indicate that we are sending a patch for a crappy > driver. > > IMHO-this-driver-is-garbage: Your Name > > If it got 10 votes of no confidence it would be moved to staging and > then deleted. Forgive my ignorance, but what is th

Re: [patch RESEND] atp870u: 64 bit bug in atp885_init()

2015-12-09 Thread Dan Carpenter
We should add a tag to indicate that we are sending a patch for a crappy driver. IMHO-this-driver-is-garbage: Your Name If it got 10 votes of no confidence it would be moved to staging and then deleted. Anyway, realistically, let's just apply this fix. It's tempting to think we could delete al

Re: [patch RESEND] atp870u: 64 bit bug in atp885_init()

2015-12-09 Thread One Thousand Gnomes
On Wed, 9 Dec 2015 16:45:12 +0300 Dan Carpenter wrote: > Everyone knows I didn't test it but it's an obvious one line fix for > memory corruption. If no one uses the code, at least this is harmless > and silences a static checker warning. > > In olden times we used to say, "Oh this bounds check

Re: [patch RESEND] atp870u: 64 bit bug in atp885_init()

2015-12-09 Thread Dan Carpenter
Everyone knows I didn't test it but it's an obvious one line fix for memory corruption. If no one uses the code, at least this is harmless and silences a static checker warning. In olden times we used to say, "Oh this bounds checking is crap but it's root only so let's leave it alone." But these

Re: [patch RESEND] atp870u: 64 bit bug in atp885_init()

2015-12-09 Thread Ondrej Zary
On Wednesday 09 December 2015 12:53:39 One Thousand Gnomes wrote: > On Wed, 9 Dec 2015 13:24:53 +0300 > Dan Carpenter wrote: > > > On 64 bit CPUs there is a memory corruption bug on probe(). It should > > be a u32 pointer instead of an unsigned long pointer or we write past > > the end of the se

Re: [patch RESEND] atp870u: 64 bit bug in atp885_init()

2015-12-09 Thread One Thousand Gnomes
On Wed, 9 Dec 2015 13:24:53 +0300 Dan Carpenter wrote: > On 64 bit CPUs there is a memory corruption bug on probe(). It should > be a u32 pointer instead of an unsigned long pointer or we write past > the end of the setupdata[] array. > > Signed-off-by: Dan Carpenter > Reviewed-by: Hannes Rein

[patch RESEND] atp870u: 64 bit bug in atp885_init()

2015-12-09 Thread Dan Carpenter
On 64 bit CPUs there is a memory corruption bug on probe(). It should be a u32 pointer instead of an unsigned long pointer or we write past the end of the setupdata[] array. Signed-off-by: Dan Carpenter Reviewed-by: Hannes Reinecke --- Resending because we have shuffled the code around so the p