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 current->stat
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
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 = &eni_dev->zero;
> > - zero->addr = p
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 like me
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
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 do
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 t
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
no
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 p
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/)
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
> --- a/
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 sol
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:
>
> drivers/atm/solos-pci.
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:
>
> drivers/atm/a
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:
>
> drivers/atm/nics
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 a/drivers/atm
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);
> > he_writel(
from include/linux/module.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 - C
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 par
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 t
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 limit
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-
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
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
>a
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 w
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 I shoul
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(&vcc->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 d
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 un
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 tw
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 s
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 ca
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
> > things
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 pppo
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
> ne
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 leaves
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 that
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
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_releas
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 CONFIG_ATM_AMBASSAD
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 o
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 y
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 linux-2.6/includ
In message <[EMAIL PROTECTED]>,Adrian Bunk writes:
>Letting CONFIG_BRIDGE depend on CONFIG_ATM doesn't sound like a good
>idea, since I doubt all people using the Bridge code require ATM
>support.
how about the following?
= net/atm/common.c 1.58 vs edited =
--- 1.58/net/atm/common.c
In message <[EMAIL PROTECTED]>,Adrian Bunk writes:
>Letting CONFIG_BRIDGE depend on CONFIG_ATM doesn't sound like a good
>idea, since I doubt all people using the Bridge code require ATM
>support.
i agree.
>Moving the hooks to the bridge code will give you exactly the same
>problems the other
In message <[EMAIL PROTECTED]>,Adrian Bunk writes:
>This patch fixes the following compile error with CONFIG_BRIDGE=y and
>CONFIG_ATM_LANE=m:
isnt the problem more that CONFIG_ATM=m not CONFIG_ATM_LANE=m?
perhaps CONFIG_BRIDGE should be dependent on CONFIG_ATM. if
atm is a module then bridge can
In message <[EMAIL PROTECTED]>,Lukasz Trabinski writes:
>OK, I think that dirver works much better with udelay() function.
good to hear. what does atmdiag say about that interface? does it have
a large percentage of tx drops?
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
quot;if" statement. This was safe, albeit MP unfriendly
>because of the spin_lock()/unlock() on each iteration.
>
>I'd say just delete the if and drop the damn
>packet.
>
>At any rate someone who has access to the golden code
>should fix this one way or another ASAP be
In message <[EMAIL PROTECTED]>,Lukasz Trabinsk
i writes:
>Sorry, but I don;t understand, what line, i am not kernel guru. :/
look for the following code:
/* retry once again? */
if(--retry > 0) {
schedule();
goto retry_here;
}
c
56 matches
Mail list logo
