Linus,
Please pull the latest irq-cleanup-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq-cleanup-for-linus
Acked by Florian.
Thanks,
tglx
------------------>
Thomas Gleixner (1):
vlynq: Convert irq functions
drivers/vlynq/vlynq.c | 64 +++++++++++++++++++++++-------------------------
1 files changed, 31 insertions(+), 33 deletions(-)
diff --git a/drivers/vlynq/vlynq.c b/drivers/vlynq/vlynq.c
index f885c86..aa250ce 100644
--- a/drivers/vlynq/vlynq.c
+++ b/drivers/vlynq/vlynq.c
@@ -135,40 +135,40 @@ static void vlynq_reset(struct vlynq_device *dev)
msleep(5);
}
-static void vlynq_irq_unmask(unsigned int irq)
+static void vlynq_irq_unmask(struct irq_data *d)
{
- u32 val;
- struct vlynq_device *dev = get_irq_chip_data(irq);
+ struct vlynq_device *dev = irq_data_get_irq_chip_data(d);
int virq;
+ u32 val;
BUG_ON(!dev);
- virq = irq - dev->irq_start;
+ virq = d->irq - dev->irq_start;
val = readl(&dev->remote->int_device[virq >> 2]);
val |= (VINT_ENABLE | virq) << VINT_OFFSET(virq);
writel(val, &dev->remote->int_device[virq >> 2]);
}
-static void vlynq_irq_mask(unsigned int irq)
+static void vlynq_irq_mask(struct irq_data *d)
{
- u32 val;
- struct vlynq_device *dev = get_irq_chip_data(irq);
+ struct vlynq_device *dev = irq_data_get_irq_chip_data(d);
int virq;
+ u32 val;
BUG_ON(!dev);
- virq = irq - dev->irq_start;
+ virq = d->irq - dev->irq_start;
val = readl(&dev->remote->int_device[virq >> 2]);
val &= ~(VINT_ENABLE << VINT_OFFSET(virq));
writel(val, &dev->remote->int_device[virq >> 2]);
}
-static int vlynq_irq_type(unsigned int irq, unsigned int flow_type)
+static int vlynq_irq_type(struct irq_data *d, unsigned int flow_type)
{
- u32 val;
- struct vlynq_device *dev = get_irq_chip_data(irq);
+ struct vlynq_device *dev = irq_data_get_irq_chip_data(d);
int virq;
+ u32 val;
BUG_ON(!dev);
- virq = irq - dev->irq_start;
+ virq = d->irq - dev->irq_start;
val = readl(&dev->remote->int_device[virq >> 2]);
switch (flow_type & IRQ_TYPE_SENSE_MASK) {
case IRQ_TYPE_EDGE_RISING:
@@ -192,10 +192,9 @@ static int vlynq_irq_type(unsigned int irq, unsigned int flow_type)
return 0;
}
-static void vlynq_local_ack(unsigned int irq)
+static void vlynq_local_ack(struct irq_data *d)
{
- struct vlynq_device *dev = get_irq_chip_data(irq);
-
+ struct vlynq_device *dev = irq_data_get_irq_chip_data(d);
u32 status = readl(&dev->local->status);
pr_debug("%s: local status: 0x%08x\n",
@@ -203,10 +202,9 @@ static void vlynq_local_ack(unsigned int irq)
writel(status, &dev->local->status);
}
-static void vlynq_remote_ack(unsigned int irq)
+static void vlynq_remote_ack(struct irq_data *d)
{
- struct vlynq_device *dev = get_irq_chip_data(irq);
-
+ struct vlynq_device *dev = irq_data_get_irq_chip_data(d);
u32 status = readl(&dev->remote->status);
pr_debug("%s: remote status: 0x%08x\n",
@@ -238,23 +236,23 @@ static irqreturn_t vlynq_irq(int irq, void *dev_id)
static struct irq_chip vlynq_irq_chip = {
.name = "vlynq",
- .unmask = vlynq_irq_unmask,
- .mask = vlynq_irq_mask,
- .set_type = vlynq_irq_type,
+ .irq_unmask = vlynq_irq_unmask,
+ .irq_mask = vlynq_irq_mask,
+ .irq_set_type = vlynq_irq_type,
};
static struct irq_chip vlynq_local_chip = {
.name = "vlynq local error",
- .unmask = vlynq_irq_unmask,
- .mask = vlynq_irq_mask,
- .ack = vlynq_local_ack,
+ .irq_unmask = vlynq_irq_unmask,
+ .irq_mask = vlynq_irq_mask,
+ .irq_ack = vlynq_local_ack,
};
static struct irq_chip vlynq_remote_chip = {
.name = "vlynq local error",
- .unmask = vlynq_irq_unmask,
- .mask = vlynq_irq_mask,
- .ack = vlynq_remote_ack,
+ .irq_unmask = vlynq_irq_unmask,
+ .irq_mask = vlynq_irq_mask,
+ .irq_ack = vlynq_remote_ack,
};
static int vlynq_setup_irq(struct vlynq_device *dev)
@@ -291,17 +289,17 @@ static int vlynq_setup_irq(struct vlynq_device *dev)
for (i = dev->irq_start; i <= dev->irq_end; i++) {
virq = i - dev->irq_start;
if (virq == dev->local_irq) {
- set_irq_chip_and_handler(i, &vlynq_local_chip,
+ irq_set_chip_and_handler(i, &vlynq_local_chip,
handle_level_irq);
- set_irq_chip_data(i, dev);
+ irq_set_chip_data(i, dev);
} else if (virq == dev->remote_irq) {
- set_irq_chip_and_handler(i, &vlynq_remote_chip,
+ irq_set_chip_and_handler(i, &vlynq_remote_chip,
handle_level_irq);
- set_irq_chip_data(i, dev);
+ irq_set_chip_data(i, dev);
} else {
- set_irq_chip_and_handler(i, &vlynq_irq_chip,
+ irq_set_chip_and_handler(i, &vlynq_irq_chip,
handle_simple_irq);
- set_irq_chip_data(i, dev);
+ irq_set_chip_data(i, dev);
writel(0, &dev->remote->int_device[virq >> 2]);
}
}
On Mon, Mar 28, 2011 at 11:50 AM, Thomas Gleixner <[email protected]> wrote:
>
> Thomas Gleixner (1):
> ? ? ?vlynq: Convert irq functions
Can we please not use those irritating "LKML-Reference" lines in the commits?
The things are a pain. They don't work for google, they don't work for
sh*t. They end up being effectively just random noise.
Either don't do them at all, or put a real pointer to a lkml archive
that is actually *useful* - even if people might worry that it isn't
going to be around forever. Eg something like
http://lkml.org/lkml/2011/3/28/439
or similar.
Who has _ever_ found a use for those email ID's? I don't know who
started doing this, but please stop it.
Linus
On Mon, 28 Mar 2011, Linus Torvalds wrote:
> On Mon, Mar 28, 2011 at 11:50 AM, Thomas Gleixner <[email protected]> wrote:
> >
> > Thomas Gleixner (1):
> > ? ? ?vlynq: Convert irq functions
>
> Can we please not use those irritating "LKML-Reference" lines in the commits?
>
> The things are a pain. They don't work for google, they don't work for
> sh*t. They end up being effectively just random noise.
>
> Either don't do them at all, or put a real pointer to a lkml archive
> that is actually *useful* - even if people might worry that it isn't
> going to be around forever. Eg something like
>
> http://lkml.org/lkml/2011/3/28/439
>
> or similar.
>
> Who has _ever_ found a use for those email ID's? I don't know who
> started doing this, but please stop it.
We started that for two reasons:
1) The commit bot replies to the original thread when we pick up a
commit, which makes our live easier as we don't have to write
"thanks, applied" mails manually.
2) msg ids are unique and can ge grepped for. also there are archives
which allow searching for them.
http://marc.info?i=alpine.LFD.2.00.1103252150180.31464@localhost6.localdomain6
http://mid.gmane.org/[email protected]
3) msg ids are never going away, but the urls will ocassionally
Thanks,
tglx
On Mon, 28 Mar 2011, Thomas Gleixner wrote:
> 2) msg ids are unique and can ge grepped for. also there are archives
> which allow searching for them.
>
> http://marc.info?i=alpine.LFD.2.00.1103252150180.31464@localhost6.localdomain6
>
> http://mid.gmane.org/[email protected]
So perhaps we should add one of those into the LKML-Reference and let
the commit bot extract the thread reference from there.
hpa ???
Thanks,
tglx
On Mon, Mar 28, 2011 at 1:29 PM, Thomas Gleixner <[email protected]> wrote:
> On Mon, 28 Mar 2011, Thomas Gleixner wrote:
>> 2) msg ids are unique and can ge grepped for. also there are archives
>> ? ?which allow searching for them.
>>
>> ? ?http://marc.info?i=alpine.LFD.2.00.1103252150180.31464@localhost6.localdomain6
>>
>> ? ?http://mid.gmane.org/[email protected]
>
> So perhaps we should add one of those into the LKML-Reference and let
> the commit bot extract the thread reference from there.
Yes. That would make it something usable to normal users.
Linus
On 03/28/2011 03:05 PM, Linus Torvalds wrote:
> On Mon, Mar 28, 2011 at 1:29 PM, Thomas Gleixner <[email protected]> wrote:
>> On Mon, 28 Mar 2011, Thomas Gleixner wrote:
>>> 2) msg ids are unique and can ge grepped for. also there are archives
>>> which allow searching for them.
>>>
>>> http://marc.info?i=alpine.LFD.2.00.1103252150180.31464@localhost6.localdomain6
>>>
>>> http://mid.gmane.org/[email protected]
>>
>> So perhaps we should add one of those into the LKML-Reference and let
>> the commit bot extract the thread reference from there.
>
> Yes. That would make it something usable to normal users.
>
My concern with that is that indexing services come and go (and which
ones that offer indexing by message-id, which is the *only* permanent
identifier, are even more subject to change), but things that go into
the git history stays forever. In IETF terms, the message-id is the
"resource name" (as in URN), as opposed to the "resource locator" (as in
URL).
There is of course the option of running a bounce service on kernel.org,
as long as the Message-ID is included.
-hpa
On Tue, Mar 29, 2011 at 11:55:49AM -0700, H. Peter Anvin wrote:
> On 03/28/2011 03:05 PM, Linus Torvalds wrote:
> > On Mon, Mar 28, 2011 at 1:29 PM, Thomas Gleixner <[email protected]> wrote:
> >> On Mon, 28 Mar 2011, Thomas Gleixner wrote:
> >>> 2) msg ids are unique and can ge grepped for. also there are archives
> >>> which allow searching for them.
> >>>
> >>> http://marc.info?i=alpine.LFD.2.00.1103252150180.31464@localhost6.localdomain6
> >>>
> >>> http://mid.gmane.org/[email protected]
> >>
> >> So perhaps we should add one of those into the LKML-Reference and let
> >> the commit bot extract the thread reference from there.
> >
> > Yes. That would make it something usable to normal users.
> >
>
> My concern with that is that indexing services come and go (and which
> ones that offer indexing by message-id, which is the *only* permanent
> identifier, are even more subject to change), but things that go into
> the git history stays forever. In IETF terms, the message-id is the
> "resource name" (as in URN), as opposed to the "resource locator" (as in
> URL).
>
> There is of course the option of running a bounce service on kernel.org,
> as long as the Message-ID is included.
Yes, this would be very useful. For example, marc.info can do something
like that; you simply go and do
http://marc.info/?i=<message-id>
and it finds you the mail messages with that id it has indexed. You can
then browse the whole thread from there.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
On Tue, Mar 29, 2011 at 11:55 AM, H. Peter Anvin <[email protected]> wrote:
>
> My concern with that is that indexing services come and go [..]
I understand the _theoretical_ argument.
But when theory and practice clash, theory is worth sh*t.
And in practice, those message-ID's are worthless. Nobody is going to
take the time to look them up.
If you want real permanence and ease of access, JUST QUOTE THE THING
YOU POINTED TO.
And if it's not important enough to quote, make it at least be useful,
obvious, and simple: make it a real web link.
Don't do the idiotic useless message-ID thing. Pick one of the two
options above, not the crazy good-for-nothing one.
Linus