public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <Uwe.Kleine-Koenig@digi.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH v2] handle failure of irqchip->set_type in setup_irq
Date: Fri, 4 Jul 2008 20:43:07 +0200	[thread overview]
Message-ID: <20080704184307.GA8076@digi.com> (raw)
In-Reply-To: <20080704101717.28f6a771.akpm@linux-foundation.org>

Hello,

Andrew Morton wrote:
> On Fri, 4 Jul 2008 12:46:34 +0200 Uwe Kleine-K__nig <Uwe.Kleine-Koenig@digi.com> wrote:
> 
> > set_type returns an int indicating success or failure, but up to now
> > setup_irq ignores that.
> >
> > In my case this resulted in a machine hang:
> > gpio-keys requested IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, but
> > arm/ns9xxx can only trigger on one direction so set_type didn't touch
> > the configuration which happens do default to a level sensitiveness and
> > returned -EINVAL.  setup_irq ignored that and unmasked the irq.  This
> > resulted in an endless triggering of the gpio-key interrupt service
> > routine which effectively killed the machine.
> >
> > With this patch applied setup_irq propagates the error to the caller.
> >
> > Note that before in the case
> >
> >       chip && !chip->set_type && !chip->name
> >
> > a NULL pointer was feed to printk.  This is fixed, too.
> >
> 
> hm, OK.  Do I recall there being some urgency to this?
No, I didn't mention this before.  (Fixing NULL-Pointers feed to printk
is a bit of a reflex for me as I used to program for Solaris and if you
feed a NULL-Pointer to printf there your program segfaults.)  I didn't
check that recently, but IIRC it's no problem here.

> 
> > +     if (ret) {
> > +             char buf[100];
> > +
> > +             snprintf(buf, sizeof(buf), KERN_ERR
> > +                             "setting flow type for irq %u failed (%%s)\n",
> > +                             irq);
> > +             print_fn_descriptor_symbol(buf, chip->set_type);
> > +     }
> 
> eww.  We really mucked up that interface. 
That's what I thought, too. ;-)  This was the nicest way I found to
print the whole line in one go.

>                                            I wonder if we can do better.
> Let me think about that.
I was about to suggest something like:

	/* WARNING: this returns a static pointer, so you cannot use the
	 * returned value after another call to creative_function_name
	 */
	char *creative_function_name(void *addr)
	{
		static char buf[SOME_LENGTH];

		... format symbol name into buf ...

		return buf;
	}

Then I could have used

	pr_err("setting flow type for irq %u failed (%s)\n",
			irq, creative_function_name(chip->set_type));

which looks definitely nicer.

Thanks for taking the patch.

Best regards
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

  reply	other threads:[~2008-07-04 18:43 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25 13:11 [PATCH] handle failure of irqchip->set_type in setup_irq Uwe Kleine-König
2008-07-02  9:17 ` Uwe Kleine-König
2008-07-02  9:49   ` Andrew Morton
2008-07-02 10:09     ` Uwe Kleine-König
2008-07-04 10:46 ` [PATCH v2] " Uwe Kleine-König
2008-07-04 17:17   ` Andrew Morton
2008-07-04 18:43     ` Uwe Kleine-König [this message]
2008-07-04 19:08       ` Andrew Morton
2008-07-09 13:13         ` Uwe Kleine-König
2008-07-09 21:52           ` Andrew Morton
2008-07-10  8:23             ` Uwe Kleine-König
2008-07-10  8:28               ` Andrew Morton
     [not found]   ` <20080704111540.ddffd241.akpm@linux-foundation.org>
     [not found]     ` <alpine.LFD.1.10.0807041147450.2815@woody.linux-foundation.org>
     [not found]       ` <alpine.LFD.1.10.0807041250220.2815@woody.linux-foundation.org>
     [not found]         ` <20080704132716.f1e12554.akpm@linux-foundation.org>
     [not found]           ` <20080704204252.GM14894@parisc-linux.org>
2008-07-04 22:01             ` the printk problem Andrew Morton
2008-07-05  2:03               ` Matthew Wilcox
2008-07-22 10:05                 ` [PATCH] Make u64 long long on all architectures (was: the printk problem) Andrew Morton
2008-07-22 10:36                   ` Michael Ellerman
2008-07-22 10:53                     ` Andrew Morton
2008-07-22 11:36                     ` Benjamin Herrenschmidt
2008-07-22 11:35                   ` Benjamin Herrenschmidt
2008-07-05 10:20               ` the printk problem Denys Vlasenko
2008-07-05 11:33               ` Jan Engelhardt
2008-07-05 12:52                 ` Vegard Nossum
2008-07-05 13:24                   ` Jan Engelhardt
2008-07-05 13:50                     ` Vegard Nossum
2008-07-05 14:07                       ` Jan Engelhardt
2008-07-05 17:56                   ` Linus Torvalds
2008-07-05 18:40                     ` Jan Engelhardt
2008-07-05 18:44                       ` Linus Torvalds
2008-07-05 18:41                     ` Vegard Nossum
2008-07-05 18:52                       ` Matthew Wilcox
2008-07-06  0:02                         ` Pekka Enberg
2008-07-06  5:17                           ` Randy Dunlap
     [not found]         ` <1215212420.8970.8.camel@pasglop>
     [not found]           ` <alpine.LFD.1.10.0807041622270.2815@woody.linux-foundation.org>
     [not found]             ` <alpine.LFD.1.10.0807051523180.2847@woody.linux-foundation.org>
     [not found]               ` <20080706052741.GA18928@elte.hu>
2008-07-06  5:37                 ` Linus Torvalds
2008-07-06  5:53                   ` Ingo Molnar
2008-07-06  6:13                     ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080704184307.GA8076@digi.com \
    --to=uwe.kleine-koenig@digi.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox