netdev - Re: [PATCH] netdev: enc28j60: use IRQF_TRIGGER

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200905261817.07161.david-b@pacbell.net>
Date:	Tue, 26 May 2009 18:17:06 -0700
From:	David Brownell <david-b@...bell.net>
To:	Mike Frysinger <vapier@...too.org>
Cc:	Baruch Siach <baruch@...s.co.il>,
	Michael Hennerich <michael.hennerich@...log.com>,
	netdev@...r.kernel.org, Bryan Wu <cooloney@...nel.org>
Subject: Re: [PATCH] netdev: enc28j60: use IRQF_TRIGGER_FALLING for IRQ by default

> > > > Right ... the appended patch will *undo* the setting
> > > > established in the board init code via set_irq_type().
> > > >
> > > > Moreover, it completely prevents working on systems which
> > > > only support "both edges" triggering.
> > >
> > > how can it provide breakage when people are forced to use set_irq_type()
> > > ?
> >
> > It reverses the IRQ setup done by the board code ...
> 
> how so ?  this code does the irq requesting which means the set_irq_type() 
> needs to come after it

No; set_irq_type() can happen at any time.  It just does setup.
One policy sets IRQ types beforehand.

Equivalently, the driver may run on hardware which only supports
one policy ... *NOT* the policy you propose the driver be changed
to require.

> anyways since the request_irq() will set any flags  
> passed to it, right ?

Wrong.  A set_irq_type() call ensures the IRQ will trigger as
specified by its parameters (unless it fails).  The current
request_irq() leaves that "default" setup alone.

Your patch changes that configuration, making it request
a trigger mode that (a) the hardware may not support, so
the request_irq() will fail; else if it succeeds, then
(b) will clobber whatever mode that was already set up.
The first certainly breaks things; the second probably
does so.

> > the code which you said they'd have to use to work
> > around the breakage your patch adds.
> 
> umm, i'm referring to code the driver and you says should be put in place -- a 
> call to set_irq_type() somewhere in the board init code.

Which is well before the driver request_irq().  As noted
above, you're trying to make the driver request a specific
IRQ type, which is *NOT* one that can necessarily be
supported.

On the other hand, the current IRQ_NONE (type == 0) is by
definition be supported *everywhere* ...

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html