Instead of fixing code that never gets compiled/test, you could probably
just remove the #if WAIT_FOR_DAEMON code which would get rid of this
raw assignment.
See the #undef around line 268.
On Mon, 23 Feb 2015 18:31:07 +0100
Fabian Frederick wrote:
> Use helper functions to access
Instead of fixing code that never gets compiled/test, you could probably
just remove the #if WAIT_FOR_DAEMON code which would get rid of this
raw assignment.
See the #undef around line 268.
On Mon, 23 Feb 2015 18:31:07 +0100
Fabian Frederick f...@skynet.be wrote:
Use helper functions to access
On Fri, 16 Jan 2015 15:10:25 +0100
Quentin Lambert wrote:
> > -u32 dma_addr = pci_map_single((struct pci_dev*)fore200e->bus_dev,
> > virt_addr, size, direction);
> > +u32 dma_addr = dma_map_single(&((struct pci_dev *)
> > fore200e->bus_dev)->dev, virt_addr, size, direction);
> >
>
Signed-off-by: Chas Williams - CONTRACTOR
---
drivers/atm/eni.c | 33 +++--
drivers/atm/fore200e.c | 22 +
drivers/atm/he.c| 125 +---
drivers/atm/he.h| 4 +-
drivers/atm/idt77252.c | 107
Signed-off-by: Chas Williams - CONTRACTOR c...@cmf.nrl.navy.mil
---
drivers/atm/eni.c | 33 +++--
drivers/atm/fore200e.c | 22 +
drivers/atm/he.c| 125 +---
drivers/atm/he.h| 4 +-
drivers/atm/idt77252.c
On Fri, 16 Jan 2015 15:10:25 +0100
Quentin Lambert lambert.quen...@gmail.com wrote:
-u32 dma_addr = pci_map_single((struct pci_dev*)fore200e-bus_dev,
virt_addr, size, direction);
+u32 dma_addr = dma_map_single(((struct pci_dev *)
fore200e-bus_dev)-dev, virt_addr, size,
On Tue, 13 Jan 2015 21:59:44 -0500 (EST)
David Miller wrote:
> From: Quentin Lambert
> Date: Mon, 12 Jan 2015 17:10:42 +0100
>
> > @@ -2246,7 +2246,8 @@ static int eni_init_one(struct pci_dev *pci_dev,
> > goto err_disable;
> >
> > zero = _dev->zero;
> > - zero->addr =
On Tue, 13 Jan 2015 21:59:44 -0500 (EST)
David Miller da...@davemloft.net wrote:
From: Quentin Lambert lambert.quen...@gmail.com
Date: Mon, 12 Jan 2015 17:10:42 +0100
@@ -2246,7 +2246,8 @@ static int eni_init_one(struct pci_dev *pci_dev,
goto err_disable;
zero =
On Mon, 12 Jan 2015 16:32:46 +0100
Quentin Lambert wrote:
>
> On 12/01/2015 16:27, chas williams - CONTRACTOR wrote:
> > There doesn't seem to be a patch for review?
> >
> I made a mistake and forgot to number the mails. I did send them though.
> Would you li
There doesn't seem to be a patch for review?
On Mon, 12 Jan 2015 11:02:39 +0100
Quentin Lambert wrote:
> This patch replaces the references to the deprecated pci api with the
> corresponding dma api.
...
> Quentin Lambert (1):
> atm: remove deprecated use of pci api
>
> drivers/atm/eni.c
On Mon, 12 Jan 2015 16:32:46 +0100
Quentin Lambert lambert.quen...@gmail.com wrote:
On 12/01/2015 16:27, chas williams - CONTRACTOR wrote:
There doesn't seem to be a patch for review?
I made a mistake and forgot to number the mails. I did send them though.
Would you like me to send them
There doesn't seem to be a patch for review?
On Mon, 12 Jan 2015 11:02:39 +0100
Quentin Lambert lambert.quen...@gmail.com wrote:
This patch replaces the references to the deprecated pci api with the
corresponding dma api.
...
Quentin Lambert (1):
atm: remove deprecated use of pci api
I don't see any reason to promote qe_tmp to a u64. I think you can
just remove the comment. Anyone trying to build this into a 64-bit
kernel will see errors from the virt_to_bus()/bus_to_virt() usage.
fp->n seems to only be manipulated in interrupt context (after driving
initialization) so it
I don't see any reason to promote qe_tmp to a u64. I think you can
just remove the comment. Anyone trying to build this into a 64-bit
kernel will see errors from the virt_to_bus()/bus_to_virt() usage.
fp-n seems to only be manipulated in interrupt context (after driving
initialization) so it
The last I heard on this topic was from Guy Ellis,
From: Guy Ellis
To: linux-atm-gene...@lists.sourceforge.net
Subject: Re: [Linux-ATM-General] solos-pci.c: Fix me
Date: Tue, 22 Jul 2014 07:34:30 +1000
Hi Chas/Nick,
I think the FIXME is reminder
The last I heard on this topic was from Guy Ellis,
From: Guy Ellis g...@traverse.com.au
To: linux-atm-gene...@lists.sourceforge.net
Subject: Re: [Linux-ATM-General] solos-pci.c: Fix me
Date: Tue, 22 Jul 2014 07:34:30 +1000
Hi Chas/Nick,
I think
One should not call blocking primitives inside a wait loop, since both
require task_struct::state to sleep, so the inner will destroy the
outer state.
sigd_enq() will possibly sleep for alloc_skb(). Move sigd_enq() before
prepare_to_wait() to avoid sleeping while waiting interruptibly. You do
One should not call blocking primitives inside a wait loop, since both
require task_struct::state to sleep, so the inner will destroy the
outer state.
sigd_enq() will possibly sleep for alloc_skb(). Move sigd_enq() before
prepare_to_wait() to avoid sleeping while waiting interruptibly. You do
On Thu, 7 Aug 2014 17:17:41 +0200
Peter Zijlstra wrote:
> Subject: atm: Fix blocking in wait loop
>
> One should not call blocking primitives inside a wait loop, since both
> require task_struct::state to sleep, so the inner will destroy the outer
> state.
>
> In this instance sigd_enq() will
On Thu, 7 Aug 2014 15:31:05 +0200 (CEST)
Julia Lawall wrote:
> diff --git a/drivers/atm/atmtcp.c b/drivers/atm/atmtcp.c
> index 0e3f8f9..c8e4fb4 100644
> --- a/drivers/atm/atmtcp.c
> +++ b/drivers/atm/atmtcp.c
> @@ -299,6 +299,7 @@ static int atmtcp_c_send(struct atm_vcc *vcc,struct
> sk_buff
On Thu, 7 Aug 2014 14:49:07 +0200
Julia Lawall wrote:
...
> drivers/atm/solos-pci.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
> index 943cf0d..7652e8d 100644
> --- a/drivers/atm/solos-pci.c
> +++ b/drivers/atm/solos-pci.c
>
On Thu, 7 Aug 2014 14:49:06 +0200
Julia Lawall wrote:
> From: Julia Lawall
>
> Convert a zero return value on error to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
On Thu, 7 Aug 2014 14:49:06 +0200
Julia Lawall julia.law...@lip6.fr wrote:
From: Julia Lawall julia.law...@lip6.fr
Convert a zero return value on error to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
On Thu, 7 Aug 2014 14:49:07 +0200
Julia Lawall julia.law...@lip6.fr wrote:
...
drivers/atm/solos-pci.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 943cf0d..7652e8d 100644
--- a/drivers/atm/solos-pci.c
+++
On Thu, 7 Aug 2014 15:31:05 +0200 (CEST)
Julia Lawall julia.law...@lip6.fr wrote:
diff --git a/drivers/atm/atmtcp.c b/drivers/atm/atmtcp.c
index 0e3f8f9..c8e4fb4 100644
--- a/drivers/atm/atmtcp.c
+++ b/drivers/atm/atmtcp.c
@@ -299,6 +299,7 @@ static int atmtcp_c_send(struct atm_vcc
On Thu, 7 Aug 2014 17:17:41 +0200
Peter Zijlstra pet...@infradead.org wrote:
Subject: atm: Fix blocking in wait loop
One should not call blocking primitives inside a wait loop, since both
require task_struct::state to sleep, so the inner will destroy the outer
state.
In this instance
Acked-by: Chas Williams
On Sun, 3 Aug 2014 17:18:20 -0700
Hans Wennborg wrote:
> Signed-off-by: Hans Wennborg
> ---
> drivers/atm/eni.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c
> index b1955ba..d65975a 100644
> ---
Acked-by: Chas Williams c...@cmf.nrl.navy.mil
On Sun, 3 Aug 2014 17:18:20 -0700
Hans Wennborg h...@hanshq.net wrote:
Signed-off-by: Hans Wennborg h...@hanshq.net
---
drivers/atm/eni.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/eni.c
On Mon, 21 Jul 2014 13:42:01 -0400
Nick Krause wrote:
> On Mon, Jul 21, 2014 at 9:14 AM, chas williams - CONTRACTOR
> wrote:
...
> > @@ -850,8 +850,7 @@ static void solos_bh(unsigned long card_arg)
> > dev
On Sun, 20 Jul 2014 00:59:42 -0400
Nick Krause wrote:
> Hey Chas,
> There seems to be a fix me in this file in the function, solos_bh.
> Is the default statement correct and I remove the fix me or
> does it need to be rewritten.
> Cheers Nick
>
I am afraid that I don't know enough about the
On Sun, 20 Jul 2014 00:59:42 -0400
Nick Krause xerofo...@gmail.com wrote:
Hey Chas,
There seems to be a fix me in this file in the function, solos_bh.
Is the default statement correct and I remove the fix me or
does it need to be rewritten.
Cheers Nick
I am afraid that I don't know enough
On Mon, 21 Jul 2014 13:42:01 -0400
Nick Krause xerofo...@gmail.com wrote:
On Mon, Jul 21, 2014 at 9:14 AM, chas williams - CONTRACTOR
c...@cmf.nrl.navy.mil wrote:
...
@@ -850,8 +850,7 @@ static void solos_bh(unsigned long card_arg)
dev_kfree_skb_any(skb
On Wed, 19 Feb 2014 14:13:54 +0900
Daeseok Youn wrote:
> >From 6297aabeff748777b520cc0ee835af0a3ddc79e2 Mon Sep 17 00:00:00 2001
> From: Daeseok Youn
> Date: Wed, 19 Feb 2014 10:49:12 +0900
> Subject: [PATCH] atm: solos-pci: make solos_bh() as static
>
> sparse says:
>
>
On Wed, 19 Feb 2014 14:11:15 +0900
Daeseok Youn wrote:
> >From 932e928d53b1e588dc17019e7f9fa7a61b8b7468 Mon Sep 17 00:00:00 2001
> From: Daeseok Youn
> Date: Wed, 19 Feb 2014 10:35:41 +0900
> Subject: [PATCH] atm: ambassador: use NULL instead of 0 for pointer
>
> sparse says:
>
>
On Wed, 19 Feb 2014 14:12:46 +0900
Daeseok Youn wrote:
> >From c320d2ea1ed51c88255c33a50c74fa3598ab7be6 Mon Sep 17 00:00:00 2001
> From: Daeseok Youn
> Date: Wed, 19 Feb 2014 10:10:11 +0900
> Subject: [PATCH] atm: nicstar: use NULL instead of 0 for pointer
>
> sparse says:
>
>
On Wed, 19 Feb 2014 14:12:46 +0900
Daeseok Youn daeseok.y...@gmail.com wrote:
From c320d2ea1ed51c88255c33a50c74fa3598ab7be6 Mon Sep 17 00:00:00 2001
From: Daeseok Youn daeseok.y...@gmail.com
Date: Wed, 19 Feb 2014 10:10:11 +0900
Subject: [PATCH] atm: nicstar: use NULL instead of 0 for pointer
On Wed, 19 Feb 2014 14:13:54 +0900
Daeseok Youn daeseok.y...@gmail.com wrote:
From 6297aabeff748777b520cc0ee835af0a3ddc79e2 Mon Sep 17 00:00:00 2001
From: Daeseok Youn daeseok.y...@gmail.com
Date: Wed, 19 Feb 2014 10:49:12 +0900
Subject: [PATCH] atm: solos-pci: make solos_bh() as static
On Wed, 19 Feb 2014 14:11:15 +0900
Daeseok Youn daeseok.y...@gmail.com wrote:
From 932e928d53b1e588dc17019e7f9fa7a61b8b7468 Mon Sep 17 00:00:00 2001
From: Daeseok Youn daeseok.y...@gmail.com
Date: Wed, 19 Feb 2014 10:35:41 +0900
Subject: [PATCH] atm: ambassador: use NULL instead of 0 for
Acked-by: Chas Williams
On Mon, 21 Oct 2013 10:12:41 +0200
Michael Opdenacker wrote:
> This patch removes a duplicate define in drivers/atm/firestream.h
>
> Signed-off-by: Michael Opdenacker
> ---
> drivers/atm/firestream.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
Acked-by: Chas Williams c...@cmf.nrl.navy.mil
On Mon, 21 Oct 2013 10:12:41 +0200
Michael Opdenacker michael.opdenac...@free-electrons.com wrote:
This patch removes a duplicate define in drivers/atm/firestream.h
Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com
---
On Fri, 26 Apr 2013 09:21:59 +0100
"David Laight" wrote:
> > ARM cannot handle udelay for more than 2 miliseconds, so we
> > should use mdelay instead for those.
> ...
> > @@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
> > he_writel(he_dev, 0x0, RESET_CNTL);
> >
On Fri, 26 Apr 2013 09:21:59 +0100
David Laight david.lai...@aculab.com wrote:
ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.
...
@@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
he_writel(he_dev, 0x0, RESET_CNTL);
ule.h:10,
> from drivers/atm/iphase.c:43:
> next/arch/s390/include/uapi/asm/ptrace.h:197:3: note: previous declaration of
> 'freg_t' was here
>
> Signed-off-by: Heiko Carstens
seems like a fine idea.
Acked-by: chas williams - CONTRACTOR
--
To unsubscribe from t
/s390/include/uapi/asm/ptrace.h:197:3: note: previous declaration of
'freg_t' was here
Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com
seems like a fine idea.
Acked-by: chas williams - CONTRACTOR c...@cmf.nrl.navy.mil
--
To unsubscribe from this list: send the line unsubscribe linux
On Mon, 4 Feb 2013 09:52:10 -0800
Tejun Heo wrote:
> Subject: atm/nicstar: convert to idr_alloc()
>
> Convert to the much saner new idr interface. The existing code looks
> buggy to me - ID 0 is treated as no-ID but allocation specifies 0 as
> lower limit and there's no error handling after
On Mon, 4 Feb 2013 09:06:24 -0800
Tejun Heo wrote:
> Hello, Chas.
>
> On Mon, Feb 04, 2013 at 09:04:10AM -0500, chas williams - CONTRACTOR wrote:
> > I don't quite understand your comment. idr_pre_get() returns 0 in the
> > case of failure.
>
> So, if you do the fo
I don't quite understand your comment. idr_pre_get() returns 0 in the
case of failure.
On Sat, 2 Feb 2013 17:20:10 -0800
Tejun Heo wrote:
> Convert to the much saner new idr interface. The existing code looks
> buggy to me - ID 0 is treated as no-ID but allocation specifies 0 as
> lower
I don't quite understand your comment. idr_pre_get() returns 0 in the
case of failure.
On Sat, 2 Feb 2013 17:20:10 -0800
Tejun Heo t...@kernel.org wrote:
Convert to the much saner new idr interface. The existing code looks
buggy to me - ID 0 is treated as no-ID but allocation specifies 0 as
On Mon, 4 Feb 2013 09:06:24 -0800
Tejun Heo t...@kernel.org wrote:
Hello, Chas.
On Mon, Feb 04, 2013 at 09:04:10AM -0500, chas williams - CONTRACTOR wrote:
I don't quite understand your comment. idr_pre_get() returns 0 in the
case of failure.
So, if you do the following,
int
On Mon, 4 Feb 2013 09:52:10 -0800
Tejun Heo t...@kernel.org wrote:
Subject: atm/nicstar: convert to idr_alloc()
Convert to the much saner new idr interface. The existing code looks
buggy to me - ID 0 is treated as no-ID but allocation specifies 0 as
lower limit and there's no error
Acked-by: chas williams - CONTRACTOR
On Fri, 28 Dec 2012 10:46:36 +0530
Tushar Behera wrote:
> Ping.
>
> On 11/16/2012 12:20 PM, Tushar Behera wrote:
> > No need to check whether unsigned variable is less than 0.
> >
> > CC: Chas Williams
> > CC: linux-
Acked-by: chas williams - CONTRACTOR c...@cmf.nrl.navy.mil
On Fri, 28 Dec 2012 10:46:36 +0530
Tushar Behera tushar.beh...@linaro.org wrote:
Ping.
On 11/16/2012 12:20 PM, Tushar Behera wrote:
No need to check whether unsigned variable is less than 0.
CC: Chas Williams c
On Fri, 30 Nov 2012 16:23:46 +
David Woodhouse wrote:
> On Fri, 2012-11-30 at 12:10 +, David Woodhouse wrote:
> > In that case I think we're fine. I'll just do the same thing in
> > br2684_push(), fix up the comment you just corrected, and we're all
> > good.
>
> OK, here's an update to
On Fri, 30 Nov 2012 16:23:46 +
David Woodhouse dw...@infradead.org wrote:
On Fri, 2012-11-30 at 12:10 +, David Woodhouse wrote:
In that case I think we're fine. I'll just do the same thing in
br2684_push(), fix up the comment you just corrected, and we're all
good.
OK, here's an
In message <1354227428.21562.230.ca...@shinybook.infradead.org>,David Woodhouse
writes:
>At this point, I think we're better off as we are (with Krzysztof's
>patch 1/7 dropped, and leaving vcc->dev->ops->close() being called
>before vcc->push(NULL). We've fairly much solved the issues with that
On Thu, 29 Nov 2012 18:11:48 +
David Woodhouse wrote:
> We do see the 'packet received for unknown VCC' complaint, after we
> reboot the host without resetting the card. And as shown in the commit I
> just referenced, we rely on the !ATM_VF_READY check in order to prevent
> a use-after-free
On Thu, 29 Nov 2012 16:24:29 +
David Woodhouse wrote:
> On Thu, 2012-11-29 at 10:59 -0500, chas williams - CONTRACTOR wrote:
> > the part that bothers me (and i dont have the programmer's guide for
> > the solos hardware) is that you are watching for the PKT_PCLOSE to be
>
On Thu, 29 Nov 2012 15:59:08 +
David Woodhouse wrote:
> On Thu, 2012-11-29 at 10:37 -0500, chas williams - CONTRACTOR wrote:
> > you shouldnt clear ATM_VF_ADDR until the vpi/vci is actually closed and
> > ready for reuse. at this point, it isnt.
>
> So
On Thu, 29 Nov 2012 15:47:57 +
David Woodhouse wrote:
> @@ -1020,12 +1048,15 @@ static uint32_t fpga_tx(struct solos_card *card)
> if (vcc) {
> atomic_inc(>stats->tx);
> solos_pop(vcc, oldskb);
> -
On Wed, 28 Nov 2012 22:18:35 +
David Woodhouse wrote:
> diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
> index 9851093..3720670 100644
> --- a/drivers/atm/solos-pci.c
> +++ b/drivers/atm/solos-pci.c
> @@ -92,6 +92,7 @@ struct pkt_hdr {
> };
>
> struct solos_skb_cb {
> +
On Thu, 29 Nov 2012 13:43:44 +0100
Krzysztof Mazur wrote:
> Removing packets from tx_queue is not needed. We can transmit packets
> also after close. We just can't call vcc->pop() after close,
> so we can just set SKB_CB(skb)->vcc of such packets to NULL so fpga_tx()
> won't call vcc->pop().
i
On Thu, 29 Nov 2012 11:57:15 +0100
Krzysztof Mazur wrote:
> or if we really want to call vcc->pop() for such skbs:
you need to call ->pop() to cleaning up the wmem_alloc accounting.
otherwise you will get complaints from the atm stack later about
freeing a vcc that had outstanding data.
--
To
On Thu, 29 Nov 2012 11:57:15 +0100
Krzysztof Mazur krzys...@podlesie.net wrote:
or if we really want to call vcc-pop() for such skbs:
you need to call -pop() to cleaning up the wmem_alloc accounting.
otherwise you will get complaints from the atm stack later about
freeing a vcc that had
On Thu, 29 Nov 2012 13:43:44 +0100
Krzysztof Mazur krzys...@podlesie.net wrote:
Removing packets from tx_queue is not needed. We can transmit packets
also after close. We just can't call vcc-pop() after close,
so we can just set SKB_CB(skb)-vcc of such packets to NULL so fpga_tx()
won't call
On Wed, 28 Nov 2012 22:18:35 +
David Woodhouse dw...@infradead.org wrote:
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 9851093..3720670 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -92,6 +92,7 @@ struct pkt_hdr {
};
struct
On Thu, 29 Nov 2012 15:47:57 +
David Woodhouse dw...@infradead.org wrote:
@@ -1020,12 +1048,15 @@ static uint32_t fpga_tx(struct solos_card *card)
if (vcc) {
atomic_inc(vcc-stats-tx);
solos_pop(vcc,
On Thu, 29 Nov 2012 15:59:08 +
David Woodhouse dw...@infradead.org wrote:
On Thu, 2012-11-29 at 10:37 -0500, chas williams - CONTRACTOR wrote:
you shouldnt clear ATM_VF_ADDR until the vpi/vci is actually closed and
ready for reuse. at this point, it isnt.
So I should always wait
On Thu, 29 Nov 2012 16:24:29 +
David Woodhouse dw...@infradead.org wrote:
On Thu, 2012-11-29 at 10:59 -0500, chas williams - CONTRACTOR wrote:
the part that bothers me (and i dont have the programmer's guide for
the solos hardware) is that you are watching for the PKT_PCLOSE to be
sent
On Thu, 29 Nov 2012 18:11:48 +
David Woodhouse dw...@infradead.org wrote:
We do see the 'packet received for unknown VCC' complaint, after we
reboot the host without resetting the card. And as shown in the commit I
just referenced, we rely on the !ATM_VF_READY check in order to prevent
a
In message 1354227428.21562.230.ca...@shinybook.infradead.org,David Woodhouse
writes:
At this point, I think we're better off as we are (with Krzysztof's
patch 1/7 dropped, and leaving vcc-dev-ops-close() being called
before vcc-push(NULL). We've fairly much solved the issues with that
On Wed, 28 Nov 2012 22:45:34 +0100
Krzysztof Mazur wrote:
> On Wed, Nov 28, 2012 at 04:20:01PM -0500, chas williams - CONTRACTOR wrote:
> > i dont like the vcc->pop() implementation and at one point i had the
> > crazy idea of using skb->destructors to handle it. however,
On Wed, 28 Nov 2012 21:18:37 +0100
Krzysztof Mazur wrote:
> On Tue, Nov 27, 2012 at 07:28:43PM +0100, Krzysztof Mazur wrote:
> > I think that we should add atm_pop() function that does that and fix all
> > drivers.
> >
>
> I'm sending a patch that implements that idea.
>
> Currently we need
On Wed, 28 Nov 2012 10:24:28 +
David Woodhouse wrote:
> On Wed, 2012-11-28 at 11:04 +0100, Krzysztof Mazur wrote:
> >
> > The ->close() routine can just abort any pending rx/tx and just wait
> > for completion of currently running rx/tx code. That shouldn't take
> > long.
>
> If it's been
On Wed, 28 Nov 2012 10:24:28 +
David Woodhouse dw...@infradead.org wrote:
On Wed, 2012-11-28 at 11:04 +0100, Krzysztof Mazur wrote:
The -close() routine can just abort any pending rx/tx and just wait
for completion of currently running rx/tx code. That shouldn't take
long.
If
On Wed, 28 Nov 2012 21:18:37 +0100
Krzysztof Mazur krzys...@podlesie.net wrote:
On Tue, Nov 27, 2012 at 07:28:43PM +0100, Krzysztof Mazur wrote:
I think that we should add atm_pop() function that does that and fix all
drivers.
I'm sending a patch that implements that idea.
Currently
On Wed, 28 Nov 2012 22:45:34 +0100
Krzysztof Mazur krzys...@podlesie.net wrote:
On Wed, Nov 28, 2012 at 04:20:01PM -0500, chas williams - CONTRACTOR wrote:
i dont like the vcc-pop() implementation and at one point i had the
crazy idea of using skb-destructors to handle it. however, i think
On Tue, 27 Nov 2012 18:02:29 +
David Woodhouse wrote:
> In solos-pci at least, the ops->close() function doesn't flush all
> pending skbs for this vcc before returning. So can be a tasklet
> somewhere which has loaded the address of the vcc->pop function from one
> of them, and is going to
On Tue, 27 Nov 2012 13:27:47 +
David Woodhouse wrote:
> > i really would prefer not to use a strange name since it might confuse
> > larger group of people who are more familiar with the traditional meaning
> > of this function. vcc_release() isnt exported so we could rename it if
> >
On Tue, 27 Nov 2012 13:27:47 +
David Woodhouse dw...@infradead.org wrote:
i really would prefer not to use a strange name since it might confuse
larger group of people who are more familiar with the traditional meaning
of this function. vcc_release() isnt exported so we could rename it
On Tue, 27 Nov 2012 18:02:29 +
David Woodhouse dw...@infradead.org wrote:
In solos-pci at least, the ops-close() function doesn't flush all
pending skbs for this vcc before returning. So can be a tasklet
somewhere which has loaded the address of the vcc-pop function from one
of them, and
In message <1352667081.9449.135.ca...@shinybook.infradead.org>,David Woodhouse
writes:
>Acked-by: David Woodhouse for your new
>version of patch #6 (returning DROP_PACKET for !VF_READY), and your
>followup to my patch #8, adding the 'need_wakeup' flag. Which we might
>as well merge into (the
In message <2012110437.ga25...@shrek.podlesie.net>,Krzysztof Mazur writes:
>Any race with testing vcc flags is probably not really important
>because:
> - vcc_release_async() does not take any lock so this check
> will be always racy so we are probably allowed to send
>
In message 2012110437.ga25...@shrek.podlesie.net,Krzysztof Mazur writes:
Any race with testing vcc flags is probably not really important
because:
- vcc_release_async() does not take any lock so this check
will be always racy so we are probably allowed to send
new
In message 1352667081.9449.135.ca...@shinybook.infradead.org,David Woodhouse
writes:
Acked-by: David Woodhouse david.woodho...@intel.com for your new
version of patch #6 (returning DROP_PACKET for !VF_READY), and your
followup to my patch #8, adding the 'need_wakeup' flag. Which we might
as well
On Tue, 6 Nov 2012 23:16:57 +0100
Krzysztof Mazur wrote:
> The atm is using atmvcc->push(vcc, NULL) callback to notify protocol
> that vcc will be closed and protocol must detach from it. This callback
> is usually used by protocol to decrement module usage count by module_put(),
> but it
On Tue, 6 Nov 2012 23:16:57 +0100
Krzysztof Mazur krzys...@podlesie.net wrote:
The atm is using atmvcc-push(vcc, NULL) callback to notify protocol
that vcc will be closed and protocol must detach from it. This callback
is usually used by protocol to decrement module usage count by
On Wed, 31 Oct 2012 23:04:35 +0100
Krzysztof Mazur wrote:
> There are also some minor potential issues in pppoatm driver:
>
> - locking issues, but now only between pppoatm_send() and
> vcc_sendmsg() and maybe some other functions,
these have been around for a while. i agree
On Wed, 31 Oct 2012 23:04:35 +0100
Krzysztof Mazur krzys...@podlesie.net wrote:
There are also some minor potential issues in pppoatm driver:
- locking issues, but now only between pppoatm_send() and
vcc_sendmsg() and maybe some other functions,
these have been around for a
On Wed, 31 Oct 2012 10:41:47 +0100
Krzysztof Mazur wrote:
> On Tue, Oct 30, 2012 at 07:20:01PM +0100, Krzysztof Mazur wrote:
> > Yes, this problem can be probably fixed by reversing close and push
> > and adding some synchronization to pppoatm_unassign_vcc(), but I think
> > we need that locking
On Wed, 31 Oct 2012 10:41:47 +0100
Krzysztof Mazur krzys...@podlesie.net wrote:
On Tue, Oct 30, 2012 at 07:20:01PM +0100, Krzysztof Mazur wrote:
Yes, this problem can be probably fixed by reversing close and push
and adding some synchronization to pppoatm_unassign_vcc(), but I think
we
In message <1350926091-12642-2-git-send-email-krzys...@podlesie.net>,Krzysztof
Mazur writes:
>The pppoatm_send() calls vcc->send() and now also checks for
>some vcc flags that indicate destroyed vcc without proper locking.
...
>The vcc_sendmsg() uses lock_sock(sk). This lock is used by
In message 1350926091-12642-2-git-send-email-krzys...@podlesie.net,Krzysztof
Mazur writes:
The pppoatm_send() calls vcc-send() and now also checks for
some vcc flags that indicate destroyed vcc without proper locking.
...
The vcc_sendmsg() uses lock_sock(sk). This lock is used by
vcc_release(),
On Tue, 31 Jul 2012 21:59:37 -0400
Shea Levy wrote:
> Hello,
>
> When building with
> MODLIB=/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/modules/3.5.0
>
> and
> ="/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/firmware",
> building Linux 3.5 with
On Tue, 31 Jul 2012 21:59:37 -0400
Shea Levy s...@shealevy.com wrote:
Hello,
When building with
MODLIB=/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/modules/3.5.0
and
=/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/firmware,
building Linux 3.5 with
In message <[EMAIL PROTECTED]>,Julia Lawall write
s:
>In each case below, I have followed the original semantics, but in
>drivers/atm/eni.c and drivers/atm/horizon.c, I have some doubts as to
>whether the original semantics is correct. In drivers/atm/eni.c, is the
>division intended to be by div
In message [EMAIL PROTECTED],Julia Lawall write
s:
In each case below, I have followed the original semantics, but in
drivers/atm/eni.c and drivers/atm/horizon.c, I have some doubts as to
whether the original semantics is correct. In drivers/atm/eni.c, is the
division intended to be by div or by
In message <[EMAIL PROTECTED]>,"Rober
t P. J. Day" writes:
>> > in any event, i just thought i'd point it out. if you're absolutely
>> > sure there will never be another call to setup_dev() from somewhere
>> > else, then, yes, it's safe.
>>
>> I understood your opinions. and partially agree with
In message [EMAIL PROTECTED],Rober
t P. J. Day writes:
in any event, i just thought i'd point it out. if you're absolutely
sure there will never be another call to setup_dev() from somewhere
else, then, yes, it's safe.
I understood your opinions. and partially agree with you.
But isn't
it might be that the userspace code shouldnt be including if_arp.h.
can you try that instead?
In message <[EMAIL PROTECTED]>,Andrew Walrond writes:
>Don't know exactly when this change went in, but it's not in 2.6.18.3
>and is in 2.6.19.2+
>
> $ diff linux/include/linux/if_arp.h
it might be that the userspace code shouldnt be including if_arp.h.
can you try that instead?
In message [EMAIL PROTECTED],Andrew Walrond writes:
Don't know exactly when this change went in, but it's not in 2.6.18.3
and is in 2.6.19.2+
$ diff linux/include/linux/if_arp.h
1 - 100 of 111 matches
Mail list logo
