Revert since we're trying to return -ENXIO from a function returning
unsigned int. Not only it causes compiler warnings it's also obviously
incorrect.
In general, watch for patches from Nick Krause since they are not even
build tested.
Signed-off-by: Sasha Levin <[email protected]>
---
arch/m68k/q40/q40ints.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 9dfa1ea..513f9bb 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -49,7 +49,7 @@ static unsigned int q40_irq_startup(struct irq_data *data)
case 1: case 2: case 8: case 9:
case 11: case 12: case 13:
printk("%s: ISA IRQ %d not implemented by HW\n", __func__, irq);
- return -ENXIO;
+ /* FIXME return -ENXIO; */
}
return 0;
}
--
1.9.1
On 07/23/2014 05:51 AM, Sasha Levin wrote:
> Revert since we're trying to return -ENXIO from a function returning
> unsigned int. Not only it causes compiler warnings it's also obviously
> incorrect.
>
> In general, watch for patches from Nick Krause since they are not even
> build tested.
>
> Signed-off-by: Sasha Levin <[email protected]>
Guess I wasn't fast enough with my comments :-(
Acked-by: Guenter Roeck <[email protected]>
> ---
> arch/m68k/q40/q40ints.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
> index 9dfa1ea..513f9bb 100644
> --- a/arch/m68k/q40/q40ints.c
> +++ b/arch/m68k/q40/q40ints.c
> @@ -49,7 +49,7 @@ static unsigned int q40_irq_startup(struct irq_data *data)
> case 1: case 2: case 8: case 9:
> case 11: case 12: case 13:
> printk("%s: ISA IRQ %d not implemented by HW\n", __func__, irq);
> - return -ENXIO;
> + /* FIXME return -ENXIO; */
> }
> return 0;
> }
>
On Wed, Jul 23, 2014 at 10:06 AM, Guenter Roeck <[email protected]> wrote:
> On 07/23/2014 05:51 AM, Sasha Levin wrote:
>>
>> Revert since we're trying to return -ENXIO from a function returning
>> unsigned int. Not only it causes compiler warnings it's also obviously
>> incorrect.
>>
>> In general, watch for patches from Nick Krause since they are not even
>> build tested.
>>
>> Signed-off-by: Sasha Levin <[email protected]>
>
>
> Guess I wasn't fast enough with my comments :-(
>
> Acked-by: Guenter Roeck <[email protected]>
>
>
>> ---
>> arch/m68k/q40/q40ints.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
>> index 9dfa1ea..513f9bb 100644
>> --- a/arch/m68k/q40/q40ints.c
>> +++ b/arch/m68k/q40/q40ints.c
>> @@ -49,7 +49,7 @@ static unsigned int q40_irq_startup(struct irq_data
>> *data)
>> case 1: case 2: case 8: case 9:
>> case 11: case 12: case 13:
>> printk("%s: ISA IRQ %d not implemented by HW\n", __func__,
>> irq);
>> - return -ENXIO;
>> + /* FIXME return -ENXIO; */
>> }
>> return 0;
>> }
>>
>
I guess this is another bad patch :(.
Nick
On Wed, 2014-07-23 at 11:39 -0400, Nick Krause wrote:
> I guess this is another bad patch :(.
This is an example of you wasting peoples time with thoughtless patches.
Please stop. You've been asked a million times.
On Wed, Jul 23, 2014 at 4:06 PM, Guenter Roeck <[email protected]> wrote:
> On 07/23/2014 05:51 AM, Sasha Levin wrote:
>> Revert since we're trying to return -ENXIO from a function returning
>> unsigned int. Not only it causes compiler warnings it's also obviously
>> incorrect.
>>
>> In general, watch for patches from Nick Krause since they are not even
>> build tested.
>>
>> Signed-off-by: Sasha Levin <[email protected]>
>
>
> Guess I wasn't fast enough with my comments :-(
>
> Acked-by: Guenter Roeck <[email protected]>
I applied Nick's cleanup (which is not yet in mainline, just in the m68k repo)
because I thought Nick was right (in this particular case ;-), cfr. my
reasoning in http://www.spinics.net/lists/kernel/msg1774736.html
W.r.t. the signess, I didn't see the compiler warning, as the version of gcc
I'm using didn't print that warning. However, irq_startup() converts the
value returned by .irq_startup() from unsigned to signed.
I assume this is just a missing conversion when the genirq framework
itself was introduced (m68k was converted quite late)?
W.r.t. the actual value, any non-zero value is treated the same.
I can change it to 1, if that makes you feel better. If returning a non-zero
value here is wrong, presumable the code has been wrong since it
incarnation.
As we're close to the opening of the merge window, it would be nice
if we could conclude on this ;-)
Thanks!
>> ---
>> arch/m68k/q40/q40ints.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
>> index 9dfa1ea..513f9bb 100644
>> --- a/arch/m68k/q40/q40ints.c
>> +++ b/arch/m68k/q40/q40ints.c
>> @@ -49,7 +49,7 @@ static unsigned int q40_irq_startup(struct irq_data
>> *data)
>> case 1: case 2: case 8: case 9:
>> case 11: case 12: case 13:
>> printk("%s: ISA IRQ %d not implemented by HW\n", __func__,
>> irq);
>> - return -ENXIO;
>> + /* FIXME return -ENXIO; */
>> }
>> return 0;
>> }
>>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 07/26/2014 11:21 AM, Geert Uytterhoeven wrote:
> I applied Nick's cleanup (which is not yet in mainline, just in the m68k repo)
> because I thought Nick was right (in this particular case ;-), cfr. my
> reasoning in http://www.spinics.net/lists/kernel/msg1774736.html
>
> W.r.t. the signess, I didn't see the compiler warning, as the version of gcc
> I'm using didn't print that warning. However, irq_startup() converts the
> value returned by .irq_startup() from unsigned to signed.
> I assume this is just a missing conversion when the genirq framework
> itself was introduced (m68k was converted quite late)?
>
> W.r.t. the actual value, any non-zero value is treated the same.
> I can change it to 1, if that makes you feel better. If returning a non-zero
> value here is wrong, presumable the code has been wrong since it
> incarnation.
>
> As we're close to the opening of the merge window, it would be nice
> if we could conclude on this ;-)
>From my standpoint there are two issues here:
1. The whole signed/unsigned mishmash here. Pretty much any solution
besides implicitly converting a signed value into an unsigned one
which then gets treated as something else entirely should be acceptable
here.
2. Beyond semantics, the original patch also changed the behaviour of
the code. What previously was a soft printk() is now a hard error.
Does it break any systems? Cornercases? I dunno, but I can assure you
that this wasn't tested at all.
To sum it up, a solution would be welcome. The patch you currently have
in the m68k repo isn't a solution.
Thanks,
Sasha
On Sat, Jul 26, 2014 at 5:33 PM, Sasha Levin <[email protected]> wrote:
> On 07/26/2014 11:21 AM, Geert Uytterhoeven wrote:
>> I applied Nick's cleanup (which is not yet in mainline, just in the m68k repo)
>> because I thought Nick was right (in this particular case ;-), cfr. my
>> reasoning in http://www.spinics.net/lists/kernel/msg1774736.html
>>
>> W.r.t. the signess, I didn't see the compiler warning, as the version of gcc
>> I'm using didn't print that warning. However, irq_startup() converts the
>> value returned by .irq_startup() from unsigned to signed.
>> I assume this is just a missing conversion when the genirq framework
>> itself was introduced (m68k was converted quite late)?
>>
>> W.r.t. the actual value, any non-zero value is treated the same.
>> I can change it to 1, if that makes you feel better. If returning a non-zero
>> value here is wrong, presumable the code has been wrong since it
>> incarnation.
>>
>> As we're close to the opening of the merge window, it would be nice
>> if we could conclude on this ;-)
>
> From my standpoint there are two issues here:
>
> 1. The whole signed/unsigned mishmash here. Pretty much any solution
> besides implicitly converting a signed value into an unsigned one
> which then gets treated as something else entirely should be acceptable
> here.
>
> 2. Beyond semantics, the original patch also changed the behaviour of
> the code. What previously was a soft printk() is now a hard error.
> Does it break any systems? Cornercases? I dunno, but I can assure you
> that this wasn't tested at all.
If it broke something, it was most probably broken before
commit c288bf2533e57174b90b07860c4391bcd1ea269c ("m68k/irq:
Rename irq_controller to irq_chip"), too.
It seems the Q40 hardware cannot handle this case, so considering this
a hard error looks fine to me (CC Richard Zidlicky).
> To sum it up, a solution would be welcome. The patch you currently have
> in the m68k repo isn't a solution.
OK, reverted. Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 07/26/2014 08:21 AM, Geert Uytterhoeven wrote:
> On Wed, Jul 23, 2014 at 4:06 PM, Guenter Roeck <[email protected]> wrote:
>> On 07/23/2014 05:51 AM, Sasha Levin wrote:
>>> Revert since we're trying to return -ENXIO from a function returning
>>> unsigned int. Not only it causes compiler warnings it's also obviously
>>> incorrect.
>>>
>>> In general, watch for patches from Nick Krause since they are not even
>>> build tested.
>>>
>>> Signed-off-by: Sasha Levin <[email protected]>
>>
>>
>> Guess I wasn't fast enough with my comments :-(
>>
>> Acked-by: Guenter Roeck <[email protected]>
>
> I applied Nick's cleanup (which is not yet in mainline, just in the m68k repo)
> because I thought Nick was right (in this particular case ;-), cfr. my
> reasoning in http://www.spinics.net/lists/kernel/msg1774736.html
>
> W.r.t. the signess, I didn't see the compiler warning, as the version of gcc
> I'm using didn't print that warning. However, irq_startup() converts the
> value returned by .irq_startup() from unsigned to signed.
> I assume this is just a missing conversion when the genirq framework
> itself was introduced (m68k was converted quite late)?
>
> W.r.t. the actual value, any non-zero value is treated the same.
> I can change it to 1, if that makes you feel better. If returning a non-zero
> value here is wrong, presumable the code has been wrong since it
> incarnation.
>
In my understanding, anything not equal to 0 means that an interrupt
is pending, not that there was an error. Maybe my understanding is wrong.
Either case, I don't really care.
Guenter