On 25 Feb 2001, Trond Myklebust wrote:
I was hopping to avoid unmounting, as I would have to shut
about everything down to do that.
It looks as if you'll have to do that. 'mount -oremount' does not
really cause the root filehandle to get updated. The only thing it
does at the
On Wed, 13 Dec 2000, James Simmons wrote:
included a patch against 2.4.0-test9 (should apply against latest but
haven't checked) which adds the config option to have a bsd-style cursor
in VT's by default. I was hoping it might be considered for inclusion so
that I don't have to patch
Intended behaviour. This is because of the access checks done in the
netlink code. Misleading, yes.
On Sun, 25 Mar 2001, James Stevenson wrote:
Hi
would somebody be able to explain to me
when you try to open /dev/tap0 which is a
character device file which has the permissions
File:
On Fri, Mar 23, 2007 at 01:43:53PM +, David Howells wrote:
[ background: On ARM, SMP synchronisation does need barriers but device
synchronisation does not. The question is that given this, whether
mb() and friends can be NOPs on ARM or not (i.e. whether mb() is
supposed to
On Sun, Mar 25, 2007 at 02:15:42PM -0700, Paul E. McKenney wrote:
[ background: On ARM, SMP synchronisation does need barriers but device
synchronisation does not. The question is that given this, whether
mb() and friends can be NOPs on ARM or not (i.e. whether mb() is
supposed
On Sun, Mar 25, 2007 at 08:24:18PM -0700, Paul E. McKenney wrote:
[ background: On ARM, SMP synchronisation does need barriers but
device
synchronisation does not. The question is that given this, whether
mb() and friends can be NOPs on ARM or not (i.e. whether mb() is
On Mon, Mar 26, 2007 at 01:07:11PM -0700, Paul E. McKenney wrote:
Does everybody agree on these semantics, though? At least David
seems to think that mb/rmb/wmb aren't required to order normal
memory accesses against each other..
Not on UP. On SMP, ordering is (almost
am not sure whether this definition actually is used in any of these files.
Am I being paranoya? anyway, adding parentheses should be safe.
--
Add parentheses to prevent operator precedence errors
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
Acked-by: Lennert Buytenhek [EMAIL PROTECTED]
Please
On Wed, Nov 28, 2007 at 11:23:57AM +0100, Jean Delvare wrote:
6a8e0e37019c0ffeb0071fae30210baf2c3bdd75
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index 2af3835..9114379 100644
---
On Wed, Oct 24, 2007 at 10:35:33PM -0500, Bill Gatliff wrote:
Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.
I don't know whether it was an ARM patch one of those kernel-wide changes.
We have futzed with the command-line parsing a bit recently, but the 2.6.23
The vendor_compatible and device_compatible fields in struct
pci_dev aren't used anywhere, and are somewhat pointless. Assuming
that these are historical artifacts, remove them.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
diff --git a/include/linux/pci.h b/include/linux/pci.h
index
pointless casts from void*
- make longer lines more readable
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
FWIW
Acked-by: Lennert Buytenhek [EMAIL PROTECTED]
---
arch/arm/mach-integrator/pci_v3.c |8 +---
arch/arm/mach-omap1/pm.c |2 +-
arch/arm/mach-sa1100/ssp.c
On Fri, Oct 26, 2007 at 05:40:22AM -0400, Jeff Garzik wrote:
arch/arm/mach-pxa/ssp.c|2 +-
arch/arm/mach-s3c2410/usb-simtec.c |2 +-
arch/arm/plat-omap/mailbox.c |2 +-
FWIW
Acked-by: Lennert Buytenhek [EMAIL PROTECTED]
-
To unsubscribe
On Sat, Oct 27, 2007 at 09:02:32PM +0100, Al Viro wrote:
diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
index 3f27239..8df230a 100644
--- a/include/linux/mv643xx_eth.h
+++ b/include/linux/mv643xx_eth.h
@@ -8,6 +8,9 @@
#define MV643XX_ETH_NAME mv643xx_eth
On Mon, Feb 11, 2008 at 02:59:34PM +0100, Thomas Gleixner wrote:
Subject: futex: disable PI/robust on archs w/o valid implementation
From: Thomas Gleixner [EMAIL PROTECTED]
We have to disable the complete PI/robust functionality for those
archs, which do not implement
On Wed, Aug 08, 2007 at 07:07:33PM -0400, Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler
On Wed, Aug 08, 2007 at 05:28:46PM -0700, Joe Perches wrote:
Some uses of printk are missing KERN_level on the second
and subsequent lines.
I'm not the ARM maintainer, but for what it's worth,
the arch/arm/kernel/ecard.c change looks fine to me.
Acked-by: Lennert Buytenhek [EMAIL PROTECTED
On Thu, Aug 02, 2007 at 01:00:21AM +0200, Mikael Pettersson wrote:
@@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op,
static inline int
futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
{
+#ifdef CONFIG_SMP
return -ENOSYS;
+#else
Since the callers
On Thu, Aug 02, 2007 at 02:06:27AM +0200, Mikael Pettersson wrote:
@@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op,
static inline int
futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
{
+#ifdef CONFIG_SMP
return -ENOSYS;
+#else
On Thu, Apr 26, 2007 at 09:41:22AM -0400, David Acker wrote:
Here is a quote from Russell that describes what I believe is the main
problem:
http://www-gatago.com/linux/kernel/15457063.html
Has e100 actually been fixed to use the PCI DMA API correctly yet?
Looking at it, it doesn't look
(please CC, not on the list)
Hi all,
IXP2000 (ARM-based) platforms use a separate 'struct resource' for PCI
MEM space. Resource allocation for PCI BARs always fails because the
'root' resource (the IXP2000 PCI MEM resource) always has the entire
address space (-) free, and
On Thu, Feb 03, 2005 at 11:51:27AM -0800, Stephen Hemminger wrote:
Recent 2.6 does a more advanced form of port randomization already
using address hash at connect time. tcp_v4_get_port is only used for
the case of applications that explicitly bind to port zero to find a
free port.
Is any
On Fri, Jul 08, 2005 at 02:34:56PM -0400, John W. Linville wrote:
Some PCI devices lose all configuration (including BARs) when
transitioning from D3hot-D0. This leaves such a device in an
inaccessible state. The patch below causes the BARs to be restored
when enabling such a device, so
On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote:
I have two 4-port e1000 NICs in the system, on a riser card.
How is the riser card wired? F.e. does it have a single edge
connector, and provides two PCI slots, or does it have a tiny
additional edge connector that routes
(please CC, not on the list.)
Hi all,
I have an embedded machine that needs a _tiny_ little bit more memory
for some of its tasks than it has. Unfortunately, it does not have
an IDE or USB controller, but it does have a 10/100 and three gigabit
ethernet interfaces.
There have been a number of
On Fri, Jan 28, 2005 at 12:14:30AM +, Russell King wrote:
The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
Hmmm, I recall e100 working fine on a Radisys ENP-2611, which has a
IXP2400 (xscale) in big-endian mode, running 2.6. This particular
board had its root fs
On Fri, Mar 01, 2013 at 06:30:13PM +0100, Alexander Holler wrote:
From: Lubomir Rintel lubo.rin...@gooddata.com
=
[ INFO: inconsistent lock state ]
3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: GW
-
On Thu, Nov 23, 2006 at 12:16:56AM +0100, Francois Romieu wrote:
You can apply the patch below and 'modprobe r8169 ignore_parity_err=1'.
Is there a way we can have this done by default on the n2100? I guess
that since it's a PCI device, there isn't much hope for that..?
-
To unsubscribe from
On Fri, Dec 15, 2006 at 09:15:22PM +0100, Francois Romieu wrote:
Is there a way we can have this done by default on the n2100? I guess
that since it's a PCI device, there isn't much hope for that..?
Do you mean an automagically tuned default value based on CONFIG_ARM ?
No, that wouldn't
On Sat, Dec 16, 2006 at 01:54:39AM +0100, Francois Romieu wrote:
No, that wouldn't make sense, that's like making a workaround depend on
arch == i386.
I'm thinking that we should somehow enable this option on the n2100
built-in r8169 ports by default only. Since the n2100 also has a
On Fri, Dec 15, 2006 at 09:14:35PM +, Russell King wrote:
Is there a way we can have this done by default on the n2100? I guess
that since it's a PCI device, there isn't much hope for that..?
Do you mean an automagically tuned default value based on CONFIG_ARM ?
No, that
On Sun, Dec 17, 2006 at 12:31:34AM +0100, Francois Romieu wrote:
Sounds good. How about something like the patch below plus the
corresponding r8169 diff?
Go wild.
Martin/Riku, I'm pretty busy with other stuff at the moment, can you
give this (on top of 2.6.20-rc1) a spin?
Index:
On Sun, Dec 17, 2006 at 11:02:10PM +0200, Riku Voipio wrote:
bah. 2.6.20-git shows nothing (with or without Lennert's patch) after
the following:
Uncompressing
Linux..done,
booting the
On Wed, Dec 06, 2006 at 12:22:26AM +, Russell King wrote:
Enabling EABI needs a compiler which supports EABI. That's where I
get fuzzy but recent gcc 4 should be suitable. I have had it suggested
to me that EABI support in the toolchain isn't all that stable at the
moment.
I use a
On Wed, Dec 06, 2006 at 04:43:14PM +, David Howells wrote:
Pre-v6 ARM doesn't support SMP according to ARM's atomic.h,
That's not quite true, there exist ARMv5 processors that in theory
can support SMP.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Wed, Dec 06, 2006 at 07:47:22PM +, David Howells wrote:
Pre-v6 ARM doesn't support SMP according to ARM's atomic.h,
That's not quite true, there exist ARMv5 processors that in theory
can support SMP.
I meant that the Linux ARM arch doesn't support it:
Ah, yes, not currently.
UART driver from going into a mode where it reports
ttyAM0: X input overrun(s) every couple of keystrokes.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Index: linux-2.6.19-rc5/drivers/serial/amba-pl010.c
===
--- linux-2.6.19-rc5
On Mon, Nov 05, 2007 at 03:23:30PM +0100, Andre Haupt wrote:
From: Andre Haupt [EMAIL PROTECTED]
Signed-off-by: Andre Haupt [EMAIL PROTECTED]
Acked-by: Lennert Buytenhek [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Fri, Jan 04, 2013 at 03:07:02PM +0100, Lubomir Rintel wrote:
From: Lubomir Rintel lubo.rin...@gooddata.com
=
[ INFO: inconsistent lock state ]
3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: GW
-
inconsistent
On Sun, Jan 06, 2013 at 08:27:22PM -0500, Nickolai Zeldovich wrote:
Do not dereference p-station_id after kfree(cmd) because p
points into the cmd data structure.
Good catch, but the patch would be better titled mwl8k.c: avoid
having a working driver, as the station_id return code _is_ needed
On Sun, Jan 06, 2013 at 10:02:14PM -0500, Nickolai Zeldovich wrote:
Good catch, but the patch would be better titled mwl8k.c: avoid
having a working driver, as the station_id return code _is_ needed
by the caller in case of success.
I'm not quite sure what you mean -- is there something
On Fri, Jul 13, 2007 at 02:12:08AM +0200, Adrian Bunk wrote:
From: John Donoghue [EMAIL PROTECTED]
CONFIG_EP93XX_ETH=y, CONFIG_MII=n results in an obvious link error.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Lennert Buytenhek [EMAIL PROTECTED]
-
To unsubscribe from this list
On Sat, Jun 30, 2007 at 04:19:23PM +0100, Matthew Garrett wrote:
I'd agree that there's a need for a state where we power down as much as
possible (even at the cost of functionality), but where possible it
would also be nice to offer a state where the mac is powered down and
the phy left
On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote:
When the interface is down (or driver removed), the BroadCom 44xx card
remains
powered on, and both its MAC and PHY is using up power.
This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
is halted,
On Sun, Jul 01, 2007 at 12:24:40AM +0200, Michael Buesch wrote:
Hm, I was going to measure the real power advantage with a
PCI-extender card. But my B44B0 card doesn't seem to work in
that extender card. It works perfectly fine sticked directly into
the motherboard, though, and other
On Thu, Jun 28, 2007 at 12:36:20PM +0200, Rodolfo Giometti wrote:
attached you can find new version of my patch for PXA27x UDC driver
support against kernel 2.6.22-rc3 (but it applies also ro rc6).
I'd like to know what I have to do in order to prepare this patch for
kernel inclusion. It's
On Sun, Jul 01, 2007 at 12:23:16PM +0200, Michael Buesch wrote:
More or less. You can't add the resistances like that, since the
bus isolation chip buffers the IDSEL signal, but it is correct that
if the host's IDSEL resistor is larger than a certain value, the
combination of the
- Forwarded message from Lennert Buytenhek [EMAIL PROTECTED] -
Date: Wed, 13 Jun 2007 20:40:40 +0200
From: Lennert Buytenhek [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: handle_futex_death() infinite loop
User-Agent: Mutt/1.4.1i
Hi,
If you're also running into glibc's tst-robust1
I'm not sure what the latest versions are, so I'm not sure which
patches to review and which patches are obsolete.
On Tue, May 08, 2007 at 02:46:28AM +0200, Krzysztof Halasa wrote:
+struct qmgr_regs __iomem *qmgr_regs;
+static struct resource *mem_res;
+static spinlock_t qmgr_lock;
+static
On Tue, May 08, 2007 at 03:19:22AM +0200, Krzysztof Halasa wrote:
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index ec4f079..f20d39d 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -101,10 +101,35
On Mon, May 07, 2007 at 02:07:16AM +0200, Krzysztof Halasa wrote:
+ * Ethernet port config (0x00 is not present on IXP42X):
+ *
+ * logical port 0x000x100x20
+ * NPE 0 (NPE-A) 1 (NPE-B) 2 (NPE-C)
+ * physical PortId 2
On Mon, May 07, 2007 at 09:18:00PM +0100, Michael-Luke Jones wrote:
Well, I'm told that (compatible) NPEs are present on other IXP CPUs.
Not sure about details.
If, by a combined effort, we ever manage to create a generic NPE
driver for the NPEs found in IXP42x/43x/46x/2000/23xx then the
On Mon, May 07, 2007 at 10:00:20PM +0200, Krzysztof Halasa wrote:
- the NPE can also be used as DMA engine and for crypto operations.
Both are not network related.
Additionally, the NPE is not only ixp4xx related, but is
also used in IXP23xx CPUs, so it could be placed in
On Tue, May 08, 2007 at 04:47:31PM +0400, Alexey Zaytsev wrote:
As with Christian's driver, I don't know whether an SRAM allocator
makes much sense. We can just set up a static allocation map for the
in-tree drivers and leave out the allocator altogether. I.e. I don't
think it's worth
On Tue, May 08, 2007 at 04:12:17PM +0200, Krzysztof Halasa wrote:
The queue manager interrupts should probably be implemented as an
irqchip, in the same way that GPIO interrupts are implemented. (I.e.
allocate 'real' interrupt numbers for them, and use the interrupt
cascade mechanism.)
On Tue, May 08, 2007 at 04:31:12PM +0200, Krzysztof Halasa wrote:
+/* Built-in 10/100 Ethernet MAC interfaces */
+static struct mac_plat_info ixdp425_plat_mac[] = {
+ {
+ .phy= 0,
+ .rxq= 3,
+ }, {
+ .phy= 1,
+
On Tue, May 08, 2007 at 05:28:21PM +0200, Krzysztof Halasa wrote:
I was always curious, why do people want to run ixp4xx in LE mode? What
are the benefits that overweight the obvious performance degradation?
Debian is indeed a valid reason.
I wonder if it would be much work to create BE
On Wed, May 09, 2007 at 10:58:06AM +0200, Marcus Better wrote:
There _is_ an ARM BE version of Debian.
It's not an official port, but it's not maintained any worse than
the 'official' LE ARM Debian port is.
Hmm... That changes a bit. Perhaps we should forget about
that LE thing
On Tue, May 08, 2007 at 06:59:36PM +0200, Krzysztof Halasa wrote:
There may be up to 6 Ethernet ports (not sure about hardware
status, not yet supported even by Intel) - 7 queues * 128 entries
each = ~ 3.5 KB. Add 2 long queues (RX) for HSS and something
for TX, and then crypto, and maybe
On Wed, May 09, 2007 at 11:35:03AM +0200, Marcus Better wrote:
Does that mean that the Debian ARM people have their heads so far
up their collective asses that they think that every form of change
is bad and are unable to accept that some forms of change might be
for the better?
Well,
On Wed, May 09, 2007 at 12:35:40PM +0200, Mikael Pettersson wrote:
Does that mean that the Debian ARM people have their heads so far
up their collective asses that they think that every form of change
is bad and are unable to accept that some forms of change might be
for the better?
On Wed, May 16, 2007 at 08:13:01AM +0100, Christoph Hellwig wrote:
+#ifndef __ARMEB__
+#warning Little endian mode not supported
+#endif
Personally I'm less fussed about WAN / LE support. Anyone with any
sense will run ixp4xx boards doing such a specialised network
operation as
On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote:
So, if the author of these patches wishes to concentrate on big-endian
support first, then we will not say (and have not said) anything which
will block inclusion of a big-endian only version of this driver.
The NSLU2 people are the
On Wed, May 16, 2007 at 09:05:18PM +0930, Rod Whitby wrote:
So, if the author of these patches wishes to concentrate on big-endian
support first, then we will not say (and have not said) anything which
will block inclusion of a big-endian only version of this driver.
The NSLU2 people
will continue my review today.
I am one of the maintainers of this architecture, (Lennert Buytenhek
is the other).
Dan has done more work on iop13xx than I have, and I'm OK with his
changes.
It's true that ARM-specific changes generally should go through the ARM
tree, but IMHO sometimes it makes
On Wed, Oct 09, 2013 at 09:27:14PM +0200, Sebastian Hesselbarth wrote:
This add a compatible for the Marvell Tauros3 cache controller which
is compatible with l2x0 cache controllers. While updating the binding
documentation, clean up the list of possible compatibles.
Signed-off-by:
On 25 Feb 2001, Trond Myklebust wrote:
> > I was hopping to avoid unmounting, as I would have to shut
> > about everything down to do that.
>
> It looks as if you'll have to do that. 'mount -oremount' does not
> really cause the root filehandle to get updated. The only thing it
>
On Wed, 13 Dec 2000, James Simmons wrote:
> > included a patch against 2.4.0-test9 (should apply against latest but
> > haven't checked) which adds the config option to have a bsd-style cursor
> > in VT's by default. I was hoping it might be considered for inclusion so
> > that I don't have to
Intended behaviour. This is because of the access checks done in the
netlink code. Misleading, yes.
On Sun, 25 Mar 2001, James Stevenson wrote:
>
> Hi
>
> would somebody be able to explain to me
> when you try to open /dev/tap0 which is a
> character device file which has the permissions
>
>
(please CC, not on the list)
Hi all,
IXP2000 (ARM-based) platforms use a separate 'struct resource' for PCI
MEM space. Resource allocation for PCI BARs always fails because the
'root' resource (the IXP2000 PCI MEM resource) always has the entire
address space (-) free, and
On Fri, Jul 08, 2005 at 02:34:56PM -0400, John W. Linville wrote:
> Some PCI devices lose all configuration (including BARs) when
> transitioning from D3hot->D0. This leaves such a device in an
> inaccessible state. The patch below causes the BARs to be restored
> when enabling such a device,
(please CC, not on the list.)
Hi all,
I have an embedded machine that needs a _tiny_ little bit more memory
for some of its tasks than it has. Unfortunately, it does not have
an IDE or USB controller, but it does have a 10/100 and three gigabit
ethernet interfaces.
There have been a number of
On Fri, Jan 28, 2005 at 12:14:30AM +, Russell King wrote:
> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
Hmmm, I recall e100 working fine on a Radisys ENP-2611, which has a
IXP2400 (xscale) in big-endian mode, running 2.6. This particular
board had its root fs
On Thu, Feb 03, 2005 at 11:51:27AM -0800, Stephen Hemminger wrote:
> Recent 2.6 does a more advanced form of port randomization already
> using address hash at connect time. tcp_v4_get_port is only used for
> the case of applications that explicitly bind to port zero to find a
> free port.
Is
On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote:
> I have two 4-port e1000 NICs in the system, on a riser card.
How is the riser card wired? F.e. does it have a single edge
connector, and provides two PCI slots, or does it have a tiny
additional edge connector that routes
UART driver from going into a mode where it reports
"ttyAM0: X input overrun(s)" every couple of keystrokes.
Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc5/drivers/serial/amba-pl010.c
===
On Wed, Dec 06, 2006 at 12:22:26AM +, Russell King wrote:
> Enabling EABI needs a compiler which supports EABI. That's where I
> get fuzzy but recent gcc 4 should be suitable. I have had it suggested
> to me that EABI support in the toolchain isn't all that stable at the
> moment.
I use a
On Wed, Dec 06, 2006 at 04:43:14PM +, David Howells wrote:
> Pre-v6 ARM doesn't support SMP according to ARM's atomic.h,
That's not quite true, there exist ARMv5 processors that in theory
can support SMP.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Wed, Dec 06, 2006 at 07:47:22PM +, David Howells wrote:
> > > Pre-v6 ARM doesn't support SMP according to ARM's atomic.h,
> >
> > That's not quite true, there exist ARMv5 processors that in theory
> > can support SMP.
>
> I meant that the Linux ARM arch doesn't support it:
Ah, yes, not
On Thu, Nov 23, 2006 at 12:16:56AM +0100, Francois Romieu wrote:
> You can apply the patch below and 'modprobe r8169 ignore_parity_err=1'.
Is there a way we can have this done by default on the n2100? I guess
that since it's a PCI device, there isn't much hope for that..?
-
To unsubscribe from
On Fri, Dec 15, 2006 at 09:15:22PM +0100, Francois Romieu wrote:
> > Is there a way we can have this done by default on the n2100? I guess
> > that since it's a PCI device, there isn't much hope for that..?
>
> Do you mean an automagically tuned default value based on CONFIG_ARM ?
No, that
On Sat, Dec 16, 2006 at 01:54:39AM +0100, Francois Romieu wrote:
> > No, that wouldn't make sense, that's like making a workaround depend on
> > arch == i386.
> >
> > I'm thinking that we should somehow enable this option on the n2100
> > built-in r8169 ports by default only. Since the n2100
On Fri, Dec 15, 2006 at 09:14:35PM +, Russell King wrote:
> > > > Is there a way we can have this done by default on the n2100? I guess
> > > > that since it's a PCI device, there isn't much hope for that..?
> > >
> > > Do you mean an automagically tuned default value based on CONFIG_ARM ?
On Sun, Dec 17, 2006 at 12:31:34AM +0100, Francois Romieu wrote:
> > Sounds good. How about something like the patch below plus the
> > corresponding r8169 diff?
>
> Go wild.
Martin/Riku, I'm pretty busy with other stuff at the moment, can you
give this (on top of 2.6.20-rc1) a spin?
On Sun, Dec 17, 2006 at 11:02:10PM +0200, Riku Voipio wrote:
> > > bah. 2.6.20-git shows nothing (with or without Lennert's patch) after
> > > the following:
>
> > > Uncompressing
> > > Linux..done,
> > >
On Fri, Mar 23, 2007 at 01:43:53PM +, David Howells wrote:
> > [ background: On ARM, SMP synchronisation does need barriers but device
> > synchronisation does not. The question is that given this, whether
> > mb() and friends can be NOPs on ARM or not (i.e. whether mb() is
> >
On Sun, Mar 25, 2007 at 02:15:42PM -0700, Paul E. McKenney wrote:
> > > [ background: On ARM, SMP synchronisation does need barriers but device
> > > synchronisation does not. The question is that given this, whether
> > > mb() and friends can be NOPs on ARM or not (i.e. whether mb() is
> >
On Sun, Mar 25, 2007 at 08:24:18PM -0700, Paul E. McKenney wrote:
> > > > > [ background: On ARM, SMP synchronisation does need barriers but
> > > > > device
> > > > > synchronisation does not. The question is that given this, whether
> > > > > mb() and friends can be NOPs on ARM or not
On Mon, Mar 26, 2007 at 01:07:11PM -0700, Paul E. McKenney wrote:
> > > > Does everybody agree on these semantics, though? At least David
> > > > seems to think that mb/rmb/wmb aren't required to order normal
> > > > memory accesses against each other..
> > >
> > > Not on UP. On SMP, ordering
On Thu, Apr 26, 2007 at 09:41:22AM -0400, David Acker wrote:
> Here is a quote from Russell that describes what I believe is the main
> problem:
> http://www-gatago.com/linux/kernel/15457063.html
> "
> Has e100 actually been fixed to use the PCI DMA API correctly yet?
> Looking at it, it doesn't
On Wed, May 16, 2007 at 08:13:01AM +0100, Christoph Hellwig wrote:
> > >>+#ifndef __ARMEB__
> > >>+#warning Little endian mode not supported
> > >>+#endif
> > >
> > >Personally I'm less fussed about WAN / LE support. Anyone with any
> > >sense will run ixp4xx boards doing such a specialised
On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote:
> So, if the author of these patches wishes to concentrate on big-endian
> support first, then we will not say (and have not said) anything which
> will block inclusion of a big-endian only version of this driver.
The NSLU2 people are
On Wed, May 16, 2007 at 09:05:18PM +0930, Rod Whitby wrote:
> >> So, if the author of these patches wishes to concentrate on big-endian
> >> support first, then we will not say (and have not said) anything which
> >> will block inclusion of a big-endian only version of this driver.
> >
> > The
the moving
> >of
> >the architecture dependant code (and explaining why) and one with the new
> >watchdog drivers? I will continue my review today.
>
> I am one of the maintainers of this architecture, (Lennert Buytenhek
> is the other).
Dan has done more work on iop13x
I'm not sure what the latest versions are, so I'm not sure which
patches to review and which patches are obsolete.
On Tue, May 08, 2007 at 02:46:28AM +0200, Krzysztof Halasa wrote:
> +struct qmgr_regs __iomem *qmgr_regs;
> +static struct resource *mem_res;
> +static spinlock_t qmgr_lock;
>
On Tue, May 08, 2007 at 03:19:22AM +0200, Krzysztof Halasa wrote:
> diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> b/arch/arm/mach-ixp4xx/ixdp425-setup.c
> index ec4f079..f20d39d 100644
> --- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> +++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
> @@ -101,10
On Mon, May 07, 2007 at 02:07:16AM +0200, Krzysztof Halasa wrote:
> + * Ethernet port config (0x00 is not present on IXP42X):
> + *
> + * logical port 0x000x100x20
> + * NPE 0 (NPE-A) 1 (NPE-B) 2 (NPE-C)
> + * physical PortId
On Mon, May 07, 2007 at 09:18:00PM +0100, Michael-Luke Jones wrote:
> >Well, I'm told that (compatible) NPEs are present on other IXP CPUs.
> >Not sure about details.
>
> If, by a combined effort, we ever manage to create a generic NPE
> driver for the NPEs found in IXP42x/43x/46x/2000/23xx
On Mon, May 07, 2007 at 10:00:20PM +0200, Krzysztof Halasa wrote:
> > - the NPE can also be used as DMA engine and for crypto operations.
> > Both are not network related.
> > Additionally, the NPE is not only ixp4xx related, but is
> > also used in IXP23xx CPUs, so it could be placed in
>
On Tue, May 08, 2007 at 04:47:31PM +0400, Alexey Zaytsev wrote:
> > As with Christian's driver, I don't know whether an SRAM allocator
> > makes much sense. We can just set up a static allocation map for the
> > in-tree drivers and leave out the allocator altogether. I.e. I don't
> > think it's
1 - 100 of 144 matches
Mail list logo
