On 07/10/15 02:41, Jiri Pirko wrote:
Thu, Jul 09, 2015 at 05:36:55PM CEST, jblu...@infradead.org wrote:
On Thu, Jul 9, 2015 at 12:07 PM, Jiri Pirko wrote:
Thu, Jul 09, 2015 at 11:58:34AM CEST, jblu...@infradead.org wrote:
The code in net/ipv6/addrconf.c:addrconf_notify() tests for
On 07/10/15 02:41, Jiri Pirko wrote:
Thu, Jul 09, 2015 at 05:36:55PM CEST, jblu...@infradead.org wrote:
On Thu, Jul 9, 2015 at 12:07 PM, Jiri Pirko wrote:
Thu, Jul 09, 2015 at 11:58:34AM CEST, jblu...@infradead.org wrote:
The code in net/ipv6/addrconf.c:addrconf_notify() tests for
On Mon, 2017-03-13 at 18:43 +0100, Andrey Konovalov wrote:
> On Thu, Jan 12, 2017 at 11:40 AM, Chas Williams <3ch...@gmail.com> wrote:
> > On Wed, 2017-01-11 at 20:36 -0800, Cong Wang wrote:
> >> On Wed, Jan 11, 2017 at 11:46 AM, Michal Hocko <mho...@kernel.org> wrote
On Mon, 2017-03-13 at 18:43 +0100, Andrey Konovalov wrote:
> On Thu, Jan 12, 2017 at 11:40 AM, Chas Williams <3ch...@gmail.com> wrote:
> > On Wed, 2017-01-11 at 20:36 -0800, Cong Wang wrote:
> >> On Wed, Jan 11, 2017 at 11:46 AM, Michal Hocko wrote:
> >> > On
On Wed, 2017-01-11 at 20:36 -0800, Cong Wang wrote:
> On Wed, Jan 11, 2017 at 11:46 AM, Michal Hocko <mho...@kernel.org> wrote:
> > On Wed 11-01-17 20:45:25, Michal Hocko wrote:
> >> On Wed 11-01-17 09:37:06, Chas Williams wrote:
> >> > On Mon, 2017-01-09 at
On Wed, 2017-01-11 at 20:36 -0800, Cong Wang wrote:
> On Wed, Jan 11, 2017 at 11:46 AM, Michal Hocko wrote:
> > On Wed 11-01-17 20:45:25, Michal Hocko wrote:
> >> On Wed 11-01-17 09:37:06, Chas Williams wrote:
> >> > On Mon, 2017-01-09 at 18:20 +0100, Andre
On Mon, 2017-01-09 at 18:20 +0100, Andrey Konovalov wrote:
> Hi!
>
> I've got the following error report while running the syzkaller fuzzer.
>
> On commit a121103c922847ba5010819a3f250f1f7fc84ab8 (4.10-rc3).
>
> A reproducer is attached.
>
> [ cut here ]
> WARNING: CPU:
On Mon, 2017-01-09 at 18:20 +0100, Andrey Konovalov wrote:
> Hi!
>
> I've got the following error report while running the syzkaller fuzzer.
>
> On commit a121103c922847ba5010819a3f250f1f7fc84ab8 (4.10-rc3).
>
> A reproducer is attached.
>
> [ cut here ]
> WARNING: CPU:
On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
I have found that your patch unfortunately does not improve the situation
for me. Here is an excerpt obtained from the dmesg of a kernel compiled
with
On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
I have found that your patch unfortunately does not improve the situation
for me. Here is an excerpt obtained from the dmesg of a kernel compiled
with
On 11/09/2016 10:57 PM, M. Vefa Bicakci wrote:
[0.002000] mvb: CPU: Physical Processor ID: 0
[0.002000] mvb: CPU: Processor Core ID: 0
[0.002000] mvb: identify_cpu:1112: c: 880013b0a040, c->logical_proc_id:
65535
[0.002000] mvb: __default_cpu_present_to_apicid:612:
On 11/09/2016 10:57 PM, M. Vefa Bicakci wrote:
[0.002000] mvb: CPU: Physical Processor ID: 0
[0.002000] mvb: CPU: Processor Core ID: 0
[0.002000] mvb: identify_cpu:1112: c: 880013b0a040, c->logical_proc_id:
65535
[0.002000] mvb: __default_cpu_present_to_apicid:612:
logical package map just works.
Reported-by: "Charles (Chas) Williams" <ciwil...@brocade.com>,
Reported-by: M. Vefa Bicakci <m@runbox.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
For 4 virtual sockets, 1 core per socket VM:
[0.235459]
logical package map just works.
Reported-by: "Charles (Chas) Williams" ,
Reported-by: M. Vefa Bicakci
Signed-off-by: Thomas Gleixner
For 4 virtual sockets, 1 core per socket VM:
[0.235459] node #0, CPUs: #1
[0.238579] Disabled fast string operations
[0.238620
On 11/09/2016 11:03 AM, Peter Zijlstra wrote:
On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote:
Both ACPI and MP specifications require that the APIC id in the respective
tables must be the same as the APIC id in CPUID.
The kernel retrieves the physical package id from the
On 11/09/2016 11:03 AM, Peter Zijlstra wrote:
On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote:
Both ACPI and MP specifications require that the APIC id in the respective
tables must be the same as the APIC id in CPUID.
The kernel retrieves the physical package id from the
On 11/08/2016 09:31 AM, Thomas Gleixner wrote:
On Tue, 8 Nov 2016, Charles (Chas) Williams wrote:
[0.016335] topology_update_package_map: apicid 0 pkg 0 cpu 0
[0.016398] smpboot: APIC(0) Converting physical 0 to logical
package 0, cpu 0 (88023fc0a040
On 11/08/2016 09:31 AM, Thomas Gleixner wrote:
On Tue, 8 Nov 2016, Charles (Chas) Williams wrote:
[0.016335] topology_update_package_map: apicid 0 pkg 0 cpu 0
[0.016398] smpboot: APIC(0) Converting physical 0 to logical
package 0, cpu 0 (88023fc0a040
On 11/07/2016 03:20 PM, Thomas Gleixner wrote:
On Mon, 7 Nov 2016, Charles (Chas) Williams wrote:
On 11/07/2016 11:19 AM, Thomas Gleixner wrote:
On Wed, 2 Nov 2016, Charles (Chas) Williams wrote:
I don't know why the CPU's phys_proc_id is 2.
max_physical_pkg_id gets initialized via
On 11/07/2016 03:20 PM, Thomas Gleixner wrote:
On Mon, 7 Nov 2016, Charles (Chas) Williams wrote:
On 11/07/2016 11:19 AM, Thomas Gleixner wrote:
On Wed, 2 Nov 2016, Charles (Chas) Williams wrote:
I don't know why the CPU's phys_proc_id is 2.
max_physical_pkg_id gets initialized via
On 11/07/2016 11:19 AM, Thomas Gleixner wrote:
On Wed, 2 Nov 2016, Charles (Chas) Williams wrote:
On 11/02/2016 08:25 AM, Sebastian Andrzej Siewior wrote:
I am not sure if this a race with the new hotplug code or something that was
always there. Both (M. Vefa Bicakc and Charles) say
On 11/07/2016 11:19 AM, Thomas Gleixner wrote:
On Wed, 2 Nov 2016, Charles (Chas) Williams wrote:
On 11/02/2016 08:25 AM, Sebastian Andrzej Siewior wrote:
I am not sure if this a race with the new hotplug code or something that was
always there. Both (M. Vefa Bicakc and Charles) say
On 11/04/2016 02:03 PM, Sebastian Andrzej Siewior wrote:
On 2016-11-04 08:20:37 [-0400], Charles (Chas) Williams wrote:
The initial CPU boots and is identified:
[0.009018] identify_boot_cpu
[0.009174] generic_identify: phys_proc_id is now 0
...
[0.009427] identify_cpu: before c
On 11/04/2016 02:03 PM, Sebastian Andrzej Siewior wrote:
On 2016-11-04 08:20:37 [-0400], Charles (Chas) Williams wrote:
The initial CPU boots and is identified:
[0.009018] identify_boot_cpu
[0.009174] generic_identify: phys_proc_id is now 0
...
[0.009427] identify_cpu: before c
On 11/03/2016 01:47 PM, Sebastian Andrzej Siewior wrote:
On 2016-11-02 18:47:49 [-0400], Charles (Chas) Williams wrote:
I don't this this is a race. Here is some debugging from the two CPU VM
(2 sockets, 1 core per socket). In identify_cpu() we have:
/* The boot/hotplug time
On 11/03/2016 01:47 PM, Sebastian Andrzej Siewior wrote:
On 2016-11-02 18:47:49 [-0400], Charles (Chas) Williams wrote:
I don't this this is a race. Here is some debugging from the two CPU VM
(2 sockets, 1 core per socket). In identify_cpu() we have:
/* The boot/hotplug time
On 11/02/2016 08:25 AM, Sebastian Andrzej Siewior wrote:
I am not sure if this a race with the new hotplug code or something that was
always there. Both (M. Vefa Bicakc and Charles) say that the box boots
sometimes fine (without the patch). smp_store_boot_cpu_info() should have run
before the
On 11/02/2016 08:25 AM, Sebastian Andrzej Siewior wrote:
I am not sure if this a race with the new hotplug code or something that was
always there. Both (M. Vefa Bicakc and Charles) say that the box boots
sometimes fine (without the patch). smp_store_boot_cpu_info() should have run
before the
On 10/28/2016 04:03 AM, Sebastian Andrzej Siewior wrote:
On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote:
I assume "init_rapl_pmus: maxpkg 4" is from init_rapl_pmus() returning
topology_max_packages(). So it says 4 but then returns 65535 for CPU 2
and 3. That -1 come
On 10/28/2016 04:03 AM, Sebastian Andrzej Siewior wrote:
On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote:
I assume "init_rapl_pmus: maxpkg 4" is from init_rapl_pmus() returning
topology_max_packages(). So it says 4 but then returns 65535 for CPU 2
and 3. That -1 come
On 10/25/2016 08:22 AM, Sebastian Andrzej Siewior wrote:
On 2016-10-21 17:03:56 [-0400], Charles (Chas) Williams wrote:
[3.107126] init_rapl_pmus: maxpkg 4
there! vmware bug. It probably worked by chance.
Yes, the behavior is a bit random.
I assume "init_rapl_pmus: max
On 10/25/2016 08:22 AM, Sebastian Andrzej Siewior wrote:
On 2016-10-21 17:03:56 [-0400], Charles (Chas) Williams wrote:
[3.107126] init_rapl_pmus: maxpkg 4
there! vmware bug. It probably worked by chance.
Yes, the behavior is a bit random.
I assume "init_rapl_pmus: max
On 10/21/2016 06:56 AM, Sebastian Andrzej Siewior wrote:
On 2016-10-20 16:27:55 [-0400], Charles (Chas) Williams wrote:
Recent 4.8 kernels have been oopsing when running under VMWare:
can you reproduce this on bare metal?
I can't get dedicated access to the specific bare metal since
On 10/21/2016 06:56 AM, Sebastian Andrzej Siewior wrote:
On 2016-10-20 16:27:55 [-0400], Charles (Chas) Williams wrote:
Recent 4.8 kernels have been oopsing when running under VMWare:
can you reproduce this on bare metal?
I can't get dedicated access to the specific bare metal since
Recent 4.8 kernels have been oopsing when running under VMWare:
[2.270203] BUG: unable to handle kernel NULL pointer dereference at
0408
[2.270325] IP: [] rapl_cpu_online+0x59/0x70
[2.270448] PGD 0
[2.270570] Oops: 0002 [#1] SMP
[2.270693] Modules linked in:
[
Recent 4.8 kernels have been oopsing when running under VMWare:
[2.270203] BUG: unable to handle kernel NULL pointer dereference at
0408
[2.270325] IP: [] rapl_cpu_online+0x59/0x70
[2.270448] PGD 0
[2.270570] Oops: 0002 [#1] SMP
[2.270693] Modules linked in:
[
On Thu, 2015-12-03 at 13:58 +0100, LABBE Corentin wrote:
> On Thu, Dec 03, 2015 at 06:26:31AM -0500, Charles (Chas) Williams wrote:
> > On Thu, 2015-12-03 at 09:06 +0100, LABBE Corentin wrote:
> > > @@ -357,11 +357,11 @@ static int process_status(struct solos_card *card,
>
On Thu, 2015-12-03 at 09:06 +0100, LABBE Corentin wrote:
> @@ -357,11 +357,11 @@ static int process_status(struct solos_card *card, int
> port, struct sk_buff *skb
> if (!str)
> return -EIO;
>
> - ver = simple_strtol(str, NULL, 10);
> - if (ver < 1) {
> + err =
On Thu, 2015-12-03 at 09:06 +0100, LABBE Corentin wrote:
> @@ -357,11 +357,11 @@ static int process_status(struct solos_card *card, int
> port, struct sk_buff *skb
> if (!str)
> return -EIO;
>
> - ver = simple_strtol(str, NULL, 10);
> - if (ver < 1) {
> + err =
On Thu, 2015-12-03 at 13:58 +0100, LABBE Corentin wrote:
> On Thu, Dec 03, 2015 at 06:26:31AM -0500, Charles (Chas) Williams wrote:
> > On Thu, 2015-12-03 at 09:06 +0100, LABBE Corentin wrote:
> > > @@ -357,11 +357,11 @@ static int process_status(struct solos_card *card,
>
On Sat, 2015-10-10 at 21:47 +0200, Tillmann Heidsieck wrote:
> this series fixes two of them. The if(); warning would require
> restructuring the code to a larger extend. Beyond this there remains a
> whooping number of > 2k checkpatch.pl warnings and errors each. Those
> can be grouped into
...
On Sat, 2015-10-10 at 21:47 +0200, Tillmann Heidsieck wrote:
> this series fixes two of them. The if(); warning would require
> restructuring the code to a larger extend. Beyond this there remains a
> whooping number of > 2k checkpatch.pl warnings and errors each. Those
> can be grouped into
...
On Wed, 2015-09-30 at 13:26 +0200, Arnd Bergmann wrote:
> The zatm_t_hist structure is not used anywhere in the kernel, but is
> exported to user space. As we are trying to eliminate uses of time_t
> in the kernel for y2038 compatibility, the current definition triggers
> checking tools because it
On Wed, 2015-09-30 at 13:26 +0200, Arnd Bergmann wrote:
> The zatm_t_hist structure is not used anywhere in the kernel, but is
> exported to user space. As we are trying to eliminate uses of time_t
> in the kernel for y2038 compatibility, the current definition triggers
> checking tools because it
On Fri, 2015-05-15 at 15:02 +, David Laight wrote:
> From: Jason A. Donenfeld
> > Sent: 13 May 2015 19:34
> > Since elt->length is a u8, we can make this variable a u8. Then we can
> > do proper bounds checking more easily. Without this, a potentially
> > negative value is passed to the memcpy
On Fri, 2015-05-15 at 15:02 +, David Laight wrote:
From: Jason A. Donenfeld
Sent: 13 May 2015 19:34
Since elt-length is a u8, we can make this variable a u8. Then we can
do proper bounds checking more easily. Without this, a potentially
negative value is passed to the memcpy inside
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
not actually need to call sigd_enq() after the initial prepare_to_wait()
because we test the termination condition before calling schedule().
Based on suggestions from Peter Zijlstra.
Signed-off-by: Chas Williams
Acked-by: Peter Zijlstra
---
net/atm/svc.c | 60
not actually need to call sigd_enq() after the initial prepare_to_wait()
because we test the termination condition before calling schedule().
Based on suggestions from Peter Zijlstra.
Signed-off-by: Chas Williams c...@cmf.n4rl.navy.mil
Acked-by: Peter Zijlstra pet...@infradead.org
---
net/atm
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
ruct
> sk_buff *skb)
> out_vcc = find_vcc(dev, ntohs(hdr->vpi), ntohs(hdr->vci));
> read_unlock(_sklist_lock);
> if (!out_vcc) {
> + result = -EUNATCH;
> atomic_inc(>stats->tx_err);
> goto done;
> }
dev_warn(>dev->dev, "Failed to allocate
> DMA bounce buffers\n");
> + err = -ENOMEM;
> /* Fallback to MMIO doesn't work */
> goto out_unmap_both;
>
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
, Failed to allocate
DMA bounce buffers\n);
+ err = -ENOMEM;
/* Fallback to MMIO doesn't work */
goto out_unmap_both;
}
Acked-by: Chas Williams c...@cmf.nrl.navy.mil
,struct
sk_buff *skb)
out_vcc = find_vcc(dev, ntohs(hdr-vpi), ntohs(hdr-vci));
read_unlock(vcc_sklist_lock);
if (!out_vcc) {
+ result = -EUNATCH;
atomic_inc(vcc-stats-tx_err);
goto done;
}
Acked-by: Chas Williams c
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 b1
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 b/drivers/atm
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
rd_arg)
> +static void solos_bh(unsigned long card_arg)
> {
> struct solos_card *card = (void *)card_arg;
> uint32_t card_flags;
Acked-by: Chas Williams
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
t ihex_binrec *rec;
> - const char *errmsg = 0;
> + const char *errmsg = NULL;
>int res;
>
> res = request_ihex_firmware(, "atmsar11.fw", >pci_dev->dev);
Acked-by: Chas Williams
--
To unsubscribe from this list: send the line "unsubscribe linux-
truct sk_buff
> *skb)
> addr2 = card->lg_addr;
> handle2 = card->lg_handle;
> card->lg_addr = 0x;
> - card->lg_handle = 0x;
> +
;
- card-lg_handle = 0x;
+ card-lg_handle = NULL;
} else {/* (!lg_addr) */
card-lg_addr = addr1;
Acked-by: Chas Williams c...@cmf.nrl.navy.mil
--
To unsubscribe from this list
(unsigned long card_arg)
{
struct solos_card *card = (void *)card_arg;
uint32_t card_flags;
Acked-by: Chas Williams c...@cmf.nrl.navy.mil
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
char *errmsg = 0;
+ const char *errmsg = NULL;
int res;
res = request_ihex_firmware(fw, atmsar11.fw, dev-pci_dev-dev);
Acked-by: Chas Williams c...@cmf.nrl.navy.mil
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
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(-)
>
&
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
t;
> Signed-off-by: Tejun Heo
> Acked-by: Chas Williams
> Reported-by: kbuild test robot
> Cc: net...@vger.kernel.org
> ---
> drivers/atm/nicstar.c | 29 +
> 1 file changed, 13 insertions(+), 16 deletions(-)
>
> --- a/drivers/atm/nicstar
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
gt; lower limit and there's no error handling after parial success. This
> conversion keeps the bugs unchanged.
>
> Only compile tested.
>
> Signed-off-by: Tejun Heo
> Cc: Chas Williams
> Cc: net...@vger.kernel.org
> ---
> This patch depends on an earlier idr changes and
as
lower limit and there's no error handling after parial success. This
conversion keeps the bugs unchanged.
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Chas Williams c...@cmf.nrl.navy.mil
Cc: net...@vger.kernel.org
---
This patch depends on an earlier idr changes
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
...@kernel.org
Acked-by: Chas Williams c...@cmf.nrl.navy.mil
Reported-by: kbuild test robot fengguang...@intel.com
Cc: net...@vger.kernel.org
---
drivers/atm/nicstar.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
--- a/drivers/atm/nicstar.c
+++ b/drivers
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
1 - 100 of 157 matches
Mail list logo
