On Fri, Feb 19, 2021 at 08:07:04PM +0200, Lennert Buytenhek wrote:
> > > IORING_OP_GETDENTS may or may not update the specified directory's
> > > file offset, and the file offset should not be relied upon having
> > > any particular value during or after
On Fri, Feb 19, 2021 at 12:34:03PM +, Matthew Wilcox wrote:
> > IORING_OP_GETDENTS may or may not update the specified directory's
> > file offset, and the file offset should not be relied upon having
> > any particular value during or after an IORING_OP_GETDENTS call.
>
> This doesn't give
and the file offset should not be relied upon having
> > any particular value during or after an IORING_OP_GETDENTS call.
> >
> > Signed-off-by: Lennert Buytenhek
> > ---
> > fs/io_uring.c | 73 +++
> > include/uapi/linux/io
ble for either using fdget_pos() or
performing the equivalent serialization by hand.
Cc: Al Viro
Signed-off-by: Lennert Buytenhek
---
fs/readdir.c | 25 +
include/linux/fs.h | 4
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/fs/readdir.c b/fs/readdi
nts().
IORING_OP_GETDENTS may or may not update the specified directory's
file offset, and the file offset should not be relied upon having
any particular value during or after an IORING_OP_GETDENTS call.
Signed-off-by: Lennert Buytenhek
---
fs/io_uring.c |
for subsequent calls, it can be set to the ->d_off field of
the last struct linux_dirent64 returned by the previous call.
Lennert Buytenhek (2):
readdir: split the core of getdents64(2) out into vfs_getdents()
io_uring: add support for IORING_OP_GETDENTS
fs/io_uring.c |
On Fri, Jan 29, 2021 at 07:37:03AM +0200, Lennert Buytenhek wrote:
> > > > One open question is whether IORING_OP_GETDENTS64 should be more like
> > > > pread(2) and allow passing in a starting offset to read from the
> > > > directory from. (This would requi
On Fri, Jan 29, 2021 at 01:07:10AM +0200, Lennert Buytenhek wrote:
> > > One open question is whether IORING_OP_GETDENTS64 should be more like
> > > pread(2) and allow passing in a starting offset to read from the
> > > directory from. (This would require some m
On Sun, Jan 24, 2021 at 10:21:38PM +, David Laight wrote:
> > One open question is whether IORING_OP_GETDENTS64 should be more like
> > pread(2) and allow passing in a starting offset to read from the
> > directory from. (This would require some more surgery in fs/readdir.c.)
>
> Since
On Sat, Jan 23, 2021 at 04:33:34PM -0700, Jens Axboe wrote:
> >> IORING_OP_GETDENTS64 behaves like getdents64(2) and takes the same
> >
> > Could we drop the '64'? We don't, for example, have IOURING_OP_FADVISE64
> > even though that's the name of the syscall.
>
> Agreed, only case we do mimic
On Sat, Jan 23, 2021 at 10:37:25AM -0700, Jens Axboe wrote:
> > IORING_OP_GETDENTS64 behaves like getdents64(2) and takes the same
> > arguments.
> >
> > Signed-off-by: Lennert Buytenhek
> > ---
> > This seems to work OK, but I'd appreciate a review from som
IORING_OP_GETDENTS64 behaves like getdents64(2) and takes the same
arguments.
Signed-off-by: Lennert Buytenhek
---
This seems to work OK, but I'd appreciate a review from someone more
familiar with io_uring internals than I am, as I'm not entirely sure
I did everything quite right.
A dumb test
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.
> >
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 Fri, Mar 01, 2013 at 06:30:13PM +0100, Alexander Holler wrote:
> >>From: Lubomir Rintel
> >>
> >>=
> >>[ INFO: inconsistent lock state ]
> >>3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: GW
> >>-
> >>inconsistent
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 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
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_
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, Jan 04, 2013 at 03:07:02PM +0100, Lubomir Rintel wrote:
> From: Lubomir Rintel
>
> =
> [ INFO: inconsistent lock state ]
> 3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: GW
> -
> inconsistent {IN-SOFTIRQ-W} ->
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 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 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
oc/proc_misc.c:464:
> per_irq_sum = kzalloc(sizeof(unsigned int)*NR_IRQS, GFP_KERNEL);
>
> I 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 preced
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, 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 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-ker
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 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
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 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 <[EMA
p.c:
> - remove 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 +---
> a
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
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
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
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
On Wed, Aug 08, 2007 at 05:28:46PM -0700, Joe Perches wrote:
> Some uses of printk are missing KERN_ 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
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 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
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 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;
>
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
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 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 <[EMAI
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
- 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
- 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
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
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.
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
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,
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
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
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 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
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 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: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
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
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?
>
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
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
> >
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 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
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
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
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
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 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 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
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;
>
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
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
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 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 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
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 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
1 - 100 of 144 matches
Mail list logo
