Le 05/01/2015 19:30, Joakim Tjernlund a écrit :
On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote:
CR only needs to be preserved when checking if we are handling a kernel address.
So we can preserve CR in a register:
- In ITLBMiss, check is done only when CONFIG_MODULES is defined.
Le 05/01/2015 19:12, Joakim Tjernlund a écrit :
On Mon, 2014-12-22 at 11:14 +0100, Christophe Leroy wrote:
On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only pages
and is set to 0 for RW pages. So we should use _PAGE_RO instead of _PAGE_RW
Signed-off-by: Christophe Leroy
Hi
Le 05/01/2015 19:12, Joakim Tjernlund a écrit :
On Mon, 2014-12-22 at 11:14 +0100, Christophe Leroy wrote:
On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only pages
and is set to 0 for RW pages. So we should use _PAGE_RO instead of _PAGE_RW
Signed-off-by: Christophe Leroy
Le 05/01/2015 19:30, Joakim Tjernlund a écrit :
On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote:
CR only needs to be preserved when checking if we are handling a kernel address.
So we can preserve CR in a register:
- In ITLBMiss, check is done only when CONFIG_MODULES is defined.
Le 24/12/2014 10:03, Stephan Mueller a écrit :
Am Dienstag, 23. Dezember 2014, 18:16:01 schrieb leroy christophe:
Hi leroy,
Le 20/12/2014 07:37, Stephan Mueller a écrit :
Am Donnerstag, 18. Dezember 2014, 13:22:20 schrieb leroy christophe:
Hi Christophe,
Le 18/12/2014 13:15, Stephan
Le 24/12/2014 10:03, Stephan Mueller a écrit :
Am Dienstag, 23. Dezember 2014, 18:16:01 schrieb leroy christophe:
Hi leroy,
Le 20/12/2014 07:37, Stephan Mueller a écrit :
Am Donnerstag, 18. Dezember 2014, 13:22:20 schrieb leroy christophe:
Hi Christophe,
Le 18/12/2014 13:15, Stephan
Le 20/12/2014 07:37, Stephan Mueller a écrit :
Am Donnerstag, 18. Dezember 2014, 13:22:20 schrieb leroy christophe:
Hi Christophe,
Le 18/12/2014 13:15, Stephan Mueller a écrit :
Hi Herbert,
While testing the vmsplice/splice interface of algif_hash I was made
aware of the problem that data
Le 20/12/2014 07:37, Stephan Mueller a écrit :
Am Donnerstag, 18. Dezember 2014, 13:22:20 schrieb leroy christophe:
Hi Christophe,
Le 18/12/2014 13:15, Stephan Mueller a écrit :
Hi Herbert,
While testing the vmsplice/splice interface of algif_hash I was made
aware of the problem that data
Le 18/12/2014 03:14, Scott Wood a écrit :
On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only)
bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of
_PAGE_RW
Signed-off-by:
Le 18/12/2014 03:14, Scott Wood a écrit :
On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only)
bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of
_PAGE_RW
Signed-off-by:
Le 18/12/2014 13:15, Stephan Mueller a écrit :
Hi Herbert,
While testing the vmsplice/splice interface of algif_hash I was made
aware of the problem that data blobs larger than 16 pages do not seem to
be hashed properly.
For testing, a file is mmap()ed and handed to vmsplice / splice. If the
Le 18/12/2014 13:15, Stephan Mueller a écrit :
Hi Herbert,
While testing the vmsplice/splice interface of algif_hash I was made
aware of the problem that data blobs larger than 16 pages do not seem to
be hashed properly.
For testing, a file is mmap()ed and handed to vmsplice / splice. If the
Le 18/12/2014 03:14, Scott Wood a écrit :
On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only)
bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of
_PAGE_RW
Signed-off-by:
Le 18/12/2014 03:22, Scott Wood a écrit :
On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only pages
and is set to 0 for RW pages. So we should use _PAGE_RO instead of _PAGE_RW
Signed-off-by: Christophe Leroy
---
v2
Le 18/12/2014 03:14, Scott Wood a écrit :
On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only)
bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of
_PAGE_RW
Signed-off-by:
Le 18/12/2014 03:22, Scott Wood a écrit :
On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only pages
and is set to 0 for RW pages. So we should use _PAGE_RO instead of _PAGE_RW
Signed-off-by: Christophe Leroy
Le 07/11/2014 04:37, Scott Wood a écrit :
On Fri, Sep 19, 2014 at 10:36:09AM +0200, LEROY Christophe wrote:
No need to re-set this bit at each TLB miss. Let's set it in the PTE.
Signed-off-by: Christophe Leroy
---
Changes in v2:
- None
Changes in v3:
- Removed PPC405 related macro from
Le 07/11/2014 04:37, Scott Wood a écrit :
On Fri, Sep 19, 2014 at 10:36:09AM +0200, LEROY Christophe wrote:
No need to re-set this bit at each TLB miss. Let's set it in the PTE.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
Changes in v2:
- None
Changes in v3:
- Removed PPC405
LINK perf
libperf.a(skip-callchain-idx.o): In function `arch_skip_callchain_idx':
/root/gen/trunk/knl/tools/perf/arch/powerpc/util/skip-callchain-idx.c:250:
undefined reference to `pr_debug'
libperf.a(skip-callchain-idx.o): In function `check_return_addr':
LINK perf
libperf.a(skip-callchain-idx.o): In function `arch_skip_callchain_idx':
/root/gen/trunk/knl/tools/perf/arch/powerpc/util/skip-callchain-idx.c:250:
undefined reference to `pr_debug'
libperf.a(skip-callchain-idx.o): In function `check_return_addr':
Le 17/09/2014 22:34, Scott Wood a écrit :
On Wed, 2014-09-17 at 22:33 +0200, christophe leroy wrote:
Le 17/09/2014 18:40, Scott Wood a écrit :
On Wed, 2014-09-17 at 18:36 +0200, Christophe Leroy wrote:
This patchset:
1) provides several MMU TLB handling optimisation on MPC8xx.
2) adds
Le 17/09/2014 22:34, Scott Wood a écrit :
On Wed, 2014-09-17 at 22:33 +0200, christophe leroy wrote:
Le 17/09/2014 18:40, Scott Wood a écrit :
On Wed, 2014-09-17 at 18:36 +0200, Christophe Leroy wrote:
This patchset:
1) provides several MMU TLB handling optimisation on MPC8xx.
2) adds
Le 08/10/2014 22:03, David Miller a écrit :
From: Christophe Leroy
Date: Tue, 7 Oct 2014 15:04:53 +0200 (CEST)
When using a MPC8xx as a router, 'perf' shows a significant time spent in
fs_enet_interrupt() and fs_enet_start_xmit().
'perf annotate' shows that the time spent in
Le 07/10/2014 02:19, Scott Wood a écrit :
On Sat, 2014-10-04 at 12:15 +0200, christophe leroy wrote:
Le 03/10/2014 22:24, Scott Wood a écrit :
On Fri, 2014-10-03 at 22:15 +0200, christophe leroy wrote:
Le 03/10/2014 16:44, Mark Brown a écrit :
On Fri, Oct 03, 2014 at 02:56:09PM +0200,
Le 07/10/2014 02:15, Scott Wood a écrit :
On Sat, 2014-10-04 at 14:02 +0200, christophe leroy wrote:
Le 03/10/2014 22:29, Scott Wood a écrit :
On Fri, 2014-10-03 at 18:49 +0200, Christophe Leroy wrote:
On CPM1, the SPI parameter RAM has a default location. In fsl_spi_cpm_get_pram()
there was
Le 07/10/2014 02:15, Scott Wood a écrit :
On Sat, 2014-10-04 at 14:02 +0200, christophe leroy wrote:
Le 03/10/2014 22:29, Scott Wood a écrit :
On Fri, 2014-10-03 at 18:49 +0200, Christophe Leroy wrote:
On CPM1, the SPI parameter RAM has a default location. In fsl_spi_cpm_get_pram()
there was
Le 07/10/2014 02:19, Scott Wood a écrit :
On Sat, 2014-10-04 at 12:15 +0200, christophe leroy wrote:
Le 03/10/2014 22:24, Scott Wood a écrit :
On Fri, 2014-10-03 at 22:15 +0200, christophe leroy wrote:
Le 03/10/2014 16:44, Mark Brown a écrit :
On Fri, Oct 03, 2014 at 02:56:09PM +0200,
Le 08/10/2014 22:03, David Miller a écrit :
From: Christophe Leroy christophe.le...@c-s.fr
Date: Tue, 7 Oct 2014 15:04:53 +0200 (CEST)
When using a MPC8xx as a router, 'perf' shows a significant time spent in
fs_enet_interrupt() and fs_enet_start_xmit().
'perf annotate' shows that the time
Le 18/09/2014 22:02, Joakim Tjernlund a écrit :
christophe leroy wrote on 2014/09/18 21:11:01:
Le 18/09/2014 20:12, Joakim Tjernlund a écrit :
leroy christophe wrote on 2014/09/18
18:42:14:
Le 18/09/2014 17:15, Joakim Tjernlund a écrit :
Christophe Leroy wrote on 2014/09/17
18:36:57
Le 18/09/2014 22:02, Joakim Tjernlund a écrit :
christophe leroy christophe.le...@c-s.fr wrote on 2014/09/18 21:11:01:
Le 18/09/2014 20:12, Joakim Tjernlund a écrit :
leroy christophe christophe.le...@c-s.fr wrote on 2014/09/18
18:42:14:
Le 18/09/2014 17:15, Joakim Tjernlund a écrit
Le 18/09/2014 17:15, Joakim Tjernlund a écrit :
Christophe Leroy wrote on 2014/09/17 18:36:57:
Exception InstructionAccess does not exist on MPC8xx. No need to branch
there from somewhere else.
Handling can be done directly in InstructionTLBError Exception.
Signed-off-by: Christophe Leroy
Le 18/09/2014 17:15, Joakim Tjernlund a écrit :
Christophe Leroy christophe.le...@c-s.fr wrote on 2014/09/17 18:36:57:
Exception InstructionAccess does not exist on MPC8xx. No need to branch
there from somewhere else.
Handling can be done directly in InstructionTLBError Exception.
Le 02/09/2014 12:41, Pablo Neira Ayuso a écrit :
On Tue, Sep 02, 2014 at 12:14:27PM +0200, leroy christophe wrote:
Calling 'iptables-compat -L', first time nothing is listed on the screen.
Second try, it generates following Oops.
I'm going to pass this patch to -stable asap:
commit
Calling 'iptables-compat -L', first time nothing is listed on the screen.
Second try, it generates following Oops.
See below the console dump and the disassembled code around the failing
address
root@vgoip:~# /usr/local/sbin/iptables-compat -L
root@vgoip:~# /usr/local/sbin/iptables-compat -L
Calling 'iptables-compat -L', first time nothing is listed on the screen.
Second try, it generates following Oops.
See below the console dump and the disassembled code around the failing
address
root@vgoip:~# /usr/local/sbin/iptables-compat -L
root@vgoip:~# /usr/local/sbin/iptables-compat -L
Le 02/09/2014 12:41, Pablo Neira Ayuso a écrit :
On Tue, Sep 02, 2014 at 12:14:27PM +0200, leroy christophe wrote:
Calling 'iptables-compat -L', first time nothing is listed on the screen.
Second try, it generates following Oops.
I'm going to pass this patch to -stable asap:
commit
8/2014 11:21, leroy christophe a écrit :
Since Linux 3.16, for all drivers tied to SPI bus, I get the following
warning on a PowerPC 8xx.
It doesn't happen with Linux 3.15
What can be the reason / what should I look at ?
[3.086957] device: 'spi32766.1': device_add
[3.087179] bus: 'spi'
-controller_state = cs;
--
cgit v0.10.1
Le 19/08/2014 11:21, leroy christophe a écrit :
Since Linux 3.16, for all drivers tied to SPI bus, I get the following
warning on a PowerPC 8xx.
It doesn't happen with Linux 3.15
What can be the reason / what should I look at ?
[3.086957] device: 'spi32766.1
Since Linux 3.16, for all drivers tied to SPI bus, I get the following
warning on a PowerPC 8xx.
It doesn't happen with Linux 3.15
What can be the reason / what should I look at ?
[3.086957] device: 'spi32766.1': device_add
[3.087179] bus: 'spi': add device spi32766.1
[3.087653]
Since Linux 3.16, for all drivers tied to SPI bus, I get the following
warning on a PowerPC 8xx.
It doesn't happen with Linux 3.15
What can be the reason / what should I look at ?
[3.086957] device: 'spi32766.1': device_add
[3.087179] bus: 'spi': add device spi32766.1
[3.087653]
Hello Segei, Florian and David,
I have an hardware with two ethernet interfaces, and with the two PHYs
inside the same component INTEL LXT973 which has only one interrupt.
I also have another hardware with two ethernet interfaces and two
independant PHYs. But the two PHYs are wired to the same
Hello Segei, Florian and David,
I have an hardware with two ethernet interfaces, and with the two PHYs
inside the same component INTEL LXT973 which has only one interrupt.
I also have another hardware with two ethernet interfaces and two
independant PHYs. But the two PHYs are wired to the same
Le 16/12/2013 23:57, Scott Wood a écrit :
On Wed, 2013-12-11 at 00:36 +0100, leroy christophe wrote:
Le 11/12/2013 00:18, Scott Wood a écrit :
There wasn't previously an ifdef specifically around the setting of
SPRN_MD_CTR. That's new. There was an ifdef around the entire block,
which has
Le 16/12/2013 23:57, Scott Wood a écrit :
On Wed, 2013-12-11 at 00:36 +0100, leroy christophe wrote:
Le 11/12/2013 00:18, Scott Wood a écrit :
There wasn't previously an ifdef specifically around the setting of
SPRN_MD_CTR. That's new. There was an ifdef around the entire block,
which has
Le 11/12/2013 00:18, Scott Wood a écrit :
On Wed, 2013-12-11 at 00:05 +0100, leroy christophe wrote:
Le 10/12/2013 23:24, Scott Wood a écrit :
On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
Today, the only way to load kernels whose size is greater than 8Mbytes is to
activate
Le 10/12/2013 23:24, Scott Wood a écrit :
On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
Today, the only way to load kernels whose size is greater than 8Mbytes is to
activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is
limited to 8Mbytes. This patch adds the
Le 10/12/2013 23:24, Scott Wood a écrit :
On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
Today, the only way to load kernels whose size is greater than 8Mbytes is to
activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is
limited to 8Mbytes. This patch adds the
Le 11/12/2013 00:18, Scott Wood a écrit :
On Wed, 2013-12-11 at 00:05 +0100, leroy christophe wrote:
Le 10/12/2013 23:24, Scott Wood a écrit :
On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
Today, the only way to load kernels whose size is greater than 8Mbytes is to
activate
Le 01/12/2013 20:38, Guenter Roeck a écrit :
On 11/30/2013 07:33 AM, Christophe Leroy wrote:
Convert mpc8xxx_wdt.c to the new watchdog API.
Signed-off-by: Christophe Leroy
diff -ur a/drivers/watchdog/mpc8xxx_wdt.c
b/drivers/watchdog/mpc8xxx_wdt.c
--- a/drivers/watchdog/mpc8xxx_wdt.c
Le 01/12/2013 20:38, Guenter Roeck a écrit :
On 11/30/2013 07:33 AM, Christophe Leroy wrote:
Convert mpc8xxx_wdt.c to the new watchdog API.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
diff -ur a/drivers/watchdog/mpc8xxx_wdt.c
b/drivers/watchdog/mpc8xxx_wdt.c
---
Scott,
The patch "Convert some mftb/mftbu into mfspr"
(beb2dc0a7a84be003ce54e98b95d65cc66e6e536) breaks startup on MPC885.
The CPU traps (SoftwareEmulation trap) at sched_clock() when trying to
read TBU with mfspr.
Reverting the patch solves the issue.
What's the prefered way to fix this
Scott,
The patch Convert some mftb/mftbu into mfspr
(beb2dc0a7a84be003ce54e98b95d65cc66e6e536) breaks startup on MPC885.
The CPU traps (SoftwareEmulation trap) at sched_clock() when trying to
read TBU with mfspr.
Reverting the patch solves the issue.
What's the prefered way to fix this ?
Le 15/10/2013 22:33, Scott Wood a écrit :
On Tue, 2013-10-15 at 18:27 +0200, leroy christophe wrote:
Le 11/10/2013 17:13, Joakim Tjernlund a écrit :
"Linuxppc-dev"
wrote on 2013/10/11 14:56:40:
Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of memory
at
bootup in
Le 11/10/2013 17:13, Joakim Tjernlund a écrit :
"Linuxppc-dev"
wrote on 2013/10/11 14:56:40:
Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of memory
at
bootup instead of 8. It is needed for "big" kernels for instance when
activating
CONFIG_LOCKDEP_SUPPORT. This needs to
Le 15/10/2013 22:33, Scott Wood a écrit :
On Tue, 2013-10-15 at 18:27 +0200, leroy christophe wrote:
Le 11/10/2013 17:13, Joakim Tjernlund a écrit :
Linuxppc-dev
linuxppc-dev-bounces+joakim.tjernlund=transmode...@lists.ozlabs.org
wrote on 2013/10/11 14:56:40:
Activating CONFIG_PIN_TLB allows
Le 11/10/2013 17:13, Joakim Tjernlund a écrit :
Linuxppc-dev
linuxppc-dev-bounces+joakim.tjernlund=transmode...@lists.ozlabs.org
wrote on 2013/10/11 14:56:40:
Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of memory
at
bootup instead of 8. It is needed for big kernels for
Le 05/10/2013 11:35, Lars-Peter Clausen a écrit :
On 10/05/2013 11:18 AM, leroy christophe wrote:
Le 05/10/2013 10:41, Lars-Peter Clausen a écrit :
On 10/05/2013 10:21 AM, Christophe Leroy wrote:
+.consumer_channel = "channel_0",
+.adc_channel_
Le 05/10/2013 10:41, Lars-Peter Clausen a écrit :
On 10/05/2013 10:21 AM, Christophe Leroy wrote:
+ .consumer_channel = "channel_0",
+ .adc_channel_label = "0",
+ },
+ {
+ .consumer_dev_name = AD7923_NAME,
+ .consumer_channel
Le 05/10/2013 10:41, Lars-Peter Clausen a écrit :
On 10/05/2013 10:21 AM, Christophe Leroy wrote:
+ .consumer_channel = channel_0,
+ .adc_channel_label = 0,
+ },
+ {
+ .consumer_dev_name = AD7923_NAME,
+ .consumer_channel =
Le 05/10/2013 11:35, Lars-Peter Clausen a écrit :
On 10/05/2013 11:18 AM, leroy christophe wrote:
Le 05/10/2013 10:41, Lars-Peter Clausen a écrit :
On 10/05/2013 10:21 AM, Christophe Leroy wrote:
+.consumer_channel = channel_0,
+.adc_channel_label = 0
Le 20/09/2013 23:22, Scott Wood a écrit :
The hardware wants to decrement; why fight it?
>I see your point.
>However it is not clear in the documentation if the decrement is done
>really after the update, or at xTLB interrupt. So I propose to still set
>the CTR ourself as described in the
Le 20/09/2013 23:22, Scott Wood a écrit :
The hardware wants to decrement; why fight it?
I see your point.
However it is not clear in the documentation if the decrement is done
really after the update, or at xTLB interrupt. So I propose to still set
the CTR ourself as described in the
Le 16/09/2013 23:02, Scott Wood a écrit :
On Fri, 2013-09-13 at 07:04 +0200, leroy christophe wrote:
Le 12/09/2013 20:44, Scott Wood a écrit :
On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
This is a reorganisation of the setup of the TLB at kernel startup, in order
to handle
Le 16/09/2013 23:02, Scott Wood a écrit :
On Fri, 2013-09-13 at 07:04 +0200, leroy christophe wrote:
Le 12/09/2013 20:44, Scott Wood a écrit :
On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
This is a reorganisation of the setup of the TLB at kernel startup, in order
to handle
Le 12/09/2013 20:44, Scott Wood a écrit :
On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
This is a reorganisation of the setup of the TLB at kernel startup, in order
to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of MPC866
and MPC885 reference manuals.
Le 12/09/2013 20:44, Scott Wood a écrit :
On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
This is a reorganisation of the setup of the TLB at kernel startup, in order
to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of MPC866
and MPC885 reference manuals.
Le 12/09/2013 02:15, Benjamin Herrenschmidt a écrit :
On Wed, 2013-09-11 at 17:36 -0500, Scott Wood wrote:
I wonder why we don't start from entry 31 so we can actually make use of
that autodecrement. What will happen when we load the first normal TLB
entry later on? I don't see any setting
Le 12/09/2013 02:15, Benjamin Herrenschmidt a écrit :
On Wed, 2013-09-11 at 17:36 -0500, Scott Wood wrote:
I wonder why we don't start from entry 31 so we can actually make use of
that autodecrement. What will happen when we load the first normal TLB
entry later on? I don't see any setting
Le 26/06/2013 01:04, Scott Wood a écrit :
On Thu, Feb 28, 2013 at 09:52:22AM +0100, LEROY Christophe wrote:
This patch modifies the behaviour of the MPC8xx/8xxx watchdog. On the MPC8xx,
at 133Mhz, the maximum timeout of the watchdog timer is 1s, which means it must
be pinged twice a second
Le 26/06/2013 01:04, Scott Wood a écrit :
On Thu, Feb 28, 2013 at 09:52:22AM +0100, LEROY Christophe wrote:
This patch modifies the behaviour of the MPC8xx/8xxx watchdog. On the MPC8xx,
at 133Mhz, the maximum timeout of the watchdog timer is 1s, which means it must
be pinged twice a second
Le 02/03/2013 22:16, Grant Likely a écrit :
I would like to know /why/ this specific hunk is necessary. I cannot
tell from the context. That's the sort of thing that is very helpful to
have in the commit description. Otherwise the patch looks fine.
g.
Ok, I will resubmit with a note to it
Le 02/03/2013 22:16, Grant Likely a écrit :
I would like to know /why/ this specific hunk is necessary. I cannot
tell from the context. That's the sort of thing that is very helpful to
have in the commit description. Otherwise the patch looks fine.
g.
Ok, I will resubmit with a note to it
Le 01/03/2013 01:43, Linus Walleij a écrit :
On Fri, Feb 22, 2013 at 10:26 AM, Christophe Leroy
wrote:
This patch allows the use of the MAX730x Driver on systems using
the Open Firmware platform format
Signed-off-by: Patrick Vasseur
Signed-off-by: Christophe Leroy
(...)
/*
Hi Wim,
Le 27/02/2013 20:52, Wim Van Sebroeck a écrit :
The rest of the code is OK and when above comments are corrected,
I will add the patch to improve the userspace experience.
Kind regards,
Wim.
Ok, I'll fix and re-submit my patch according to your comments.
Best regards
Christophe
--
Hi Wim,
Le 27/02/2013 20:52, Wim Van Sebroeck a écrit :
The rest of the code is OK and when above comments are corrected,
I will add the patch to improve the userspace experience.
Kind regards,
Wim.
Ok, I'll fix and re-submit my patch according to your comments.
Best regards
Christophe
--
Le 01/03/2013 01:43, Linus Walleij a écrit :
On Fri, Feb 22, 2013 at 10:26 AM, Christophe Leroy
christophe.le...@c-s.fr wrote:
This patch allows the use of the MAX730x Driver on systems using
the Open Firmware platform format
Signed-off-by: Patrick Vasseur patrick.vass...@c-s.fr
Le 21/02/2013 22:14, Michal Marek a écrit :
Dne 21.2.2013 13:49, Christophe Leroy napsal(a):
This patch allows the use of setlocalversion script regardless of the LANG
parameter. Otherwise, the `svn info 2>/dev/null | grep '^Last Changed Rev'`
returns nothing because for instance, in French the
Le 21/02/2013 22:14, Michal Marek a écrit :
Dne 21.2.2013 13:49, Christophe Leroy napsal(a):
This patch allows the use of setlocalversion script regardless of the LANG
parameter. Otherwise, the `svn info 2/dev/null | grep '^Last Changed Rev'`
returns nothing because for instance, in French the
Le 12/02/2013 19:54, Lars-Peter Clausen a écrit :
On 02/12/2013 06:10 PM, Christophe Leroy wrote:
This patch adds support for Analog Devices AD7923 ADC in the IIO Subsystem.
Signed-off-by: Patrick Vasseur
Signed-off-by: Christophe Leroy
Looks good to me except for one small, but important
Le 12/02/2013 19:54, Lars-Peter Clausen a écrit :
On 02/12/2013 06:10 PM, Christophe Leroy wrote:
This patch adds support for Analog Devices AD7923 ADC in the IIO Subsystem.
Signed-off-by: Patrick Vasseur patrick.vass...@c-s.fr
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
Looks
Le 24/09/2012 20:30, Richard Cochran a écrit :
On Mon, Sep 24, 2012 at 04:00:58PM +0200, Christophe Leroy wrote:
diff -u a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c
--- a/drivers/net/phy/lxt.c 2012-09-23 03:08:48.0 +0200
+++ b/drivers/net/phy/lxt.c 2012-09-23
Le 24/09/2012 20:30, Richard Cochran a écrit :
On Mon, Sep 24, 2012 at 04:00:58PM +0200, Christophe Leroy wrote:
diff -u a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c
--- a/drivers/net/phy/lxt.c 2012-09-23 03:08:48.0 +0200
+++ b/drivers/net/phy/lxt.c 2012-09-23
Le 24/09/2012 16:13, David Laight a écrit :
This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
precautions linked to ERRATA Item 4:
Revision A2 of LXT973 chip randomly returns the contents of the previous even
register when you read a odd register regularly
Does
Le 24/09/2012 16:13, David Laight a écrit :
This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
precautions linked to ERRATA Item 4:
Revision A2 of LXT973 chip randomly returns the contents of the previous even
register when you read a odd register regularly
Does
Le 10/09/2012 20:17, Lutz Jaenicke a écrit :
On Mon, Sep 10, 2012 at 05:45:49PM +0200, Christophe Leroy wrote:
This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
precautions linked to ERRATA Item 4:
Item 4: MDIO Interface and Repeated Polling
Problem: Repeated
Le 10/09/2012 20:17, Lutz Jaenicke a écrit :
On Mon, Sep 10, 2012 at 05:45:49PM +0200, Christophe Leroy wrote:
This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
precautions linked to ERRATA Item 4:
Item 4: MDIO Interface and Repeated Polling
Problem: Repeated
Le 16/08/2012 17:21, Alan Cox a écrit :
MAX_IDL: Maximum idle characters. When a character is received, the
receiver begins counting idle characters. If MAX_IDL idle characters
are received before the next data character, an idle timeout occurs
and the buffer is closed,
generating a maskable
Le 16/08/2012 17:21, Alan Cox a écrit :
MAX_IDL: Maximum idle characters. When a character is received, the
receiver begins counting idle characters. If MAX_IDL idle characters
are received before the next data character, an idle timeout occurs
and the buffer is closed,
generating a maskable
Le 26/08/2012 19:47, Guenter Roeck a écrit :
On Thu, Aug 23, 2012 at 11:13:17AM -0700, Guenter Roeck wrote:
On Thu, Aug 23, 2012 at 05:32:12PM +0200, Christophe Leroy wrote:
Hello,
Hi Christophe,
Hi again,
[ ... ]
Hi Guenter,
- /* 3-wire link (shared SI/SO) for LM70 */
- if
Le 26/08/2012 19:47, Guenter Roeck a écrit :
On Thu, Aug 23, 2012 at 11:13:17AM -0700, Guenter Roeck wrote:
On Thu, Aug 23, 2012 at 05:32:12PM +0200, Christophe Leroy wrote:
Hello,
Hi Christophe,
Hi again,
[ ... ]
Hi Guenter,
- /* 3-wire link (shared SI/SO) for LM70 */
- if
Le 16/08/2012 16:29, Alan Cox a écrit :
The PowerPC CPM is working differently. It doesn't use a fifo but
buffers. Buffers are handed to the microprocessor only when they are
full or after a timeout period which is adjustable. In the driver, the
Which is different how - remembering we empty the
Le 14/08/2012 16:52, Alan Cox a écrit :
On Tue, 14 Aug 2012 16:26:28 +0200
Christophe Leroy wrote:
Hello,
I'm not sure who to address this Patch to either
It fixes a delay issue with CPM UART driver on Powerpc MPC8xx.
The problem is that with the actual code, the driver waits 32 IDLE
Le 14/08/2012 16:52, Alan Cox a écrit :
On Tue, 14 Aug 2012 16:26:28 +0200
Christophe Leroy christophe.le...@c-s.fr wrote:
Hello,
I'm not sure who to address this Patch to either
It fixes a delay issue with CPM UART driver on Powerpc MPC8xx.
The problem is that with the actual code, the
Le 16/08/2012 16:29, Alan Cox a écrit :
The PowerPC CPM is working differently. It doesn't use a fifo but
buffers. Buffers are handed to the microprocessor only when they are
full or after a timeout period which is adjustable. In the driver, the
Which is different how - remembering we empty the
Le 05/08/2012 10:28, Eric Dumazet a écrit :
On Sun, 2012-08-05 at 10:16 +0200, LEROY christophe wrote:
Le 02/08/2012 16:13, Eric Dumazet a écrit :
On Thu, 2012-08-02 at 14:27 +0200, leroy christophe wrote:
Hi
I'm having a big issue with UDP. Using a powerpc board (MPC860).
With our board
Le 05/08/2012 10:28, Eric Dumazet a écrit :
On Sun, 2012-08-05 at 10:16 +0200, LEROY christophe wrote:
Le 02/08/2012 16:13, Eric Dumazet a écrit :
On Thu, 2012-08-02 at 14:27 +0200, leroy christophe wrote:
Hi
I'm having a big issue with UDP. Using a powerpc board (MPC860).
With our board
Le 02/08/2012 16:13, Eric Dumazet a écrit :
On Thu, 2012-08-02 at 14:27 +0200, leroy christophe wrote:
Hi
I'm having a big issue with UDP. Using a powerpc board (MPC860).
With our board running kernel 2.4.17, I'm able to send 16 voice
packets (UDP, 96 bytes per packet) in 11 seconds
Le 02/08/2012 16:13, Eric Dumazet a écrit :
On Thu, 2012-08-02 at 14:27 +0200, leroy christophe wrote:
Hi
I'm having a big issue with UDP. Using a powerpc board (MPC860).
With our board running kernel 2.4.17, I'm able to send 16 voice
packets (UDP, 96 bytes per packet) in 11 seconds
Hi
I'm having a big issue with UDP. Using a powerpc board (MPC860).
With our board running kernel 2.4.17, I'm able to send 16 voice
packets (UDP, 96 bytes per packet) in 11 seconds.
With the same board running either Kernel 2.6.35.14 or Kernel 3.4.7, I
need 55 seconds to send the same
Hi
I'm having a big issue with UDP. Using a powerpc board (MPC860).
With our board running kernel 2.4.17, I'm able to send 16 voice
packets (UDP, 96 bytes per packet) in 11 seconds.
With the same board running either Kernel 2.6.35.14 or Kernel 3.4.7, I
need 55 seconds to send the same
101 - 200 of 200 matches
Mail list logo
