On Mon, Jul 04, 2005 at 01:24:05AM +0200, Adrian Bunk wrote:
> This patch I sent on 13 May 2005 is still not in Linus' tree, and now
> it's July.
Sorry, I missed the original thread. Feel free to CC me in future.
> What shall I do?
> - resend this patch with the removal date set to August or
On Mon, Jul 04, 2005 at 01:24:05AM +0200, Adrian Bunk wrote:
This patch I sent on 13 May 2005 is still not in Linus' tree, and now
it's July.
Sorry, I missed the original thread. Feel free to CC me in future.
What shall I do?
- resend this patch with the removal date set to August or
That
On Tue, Apr 19, 2005 at 02:45:23AM +0200, Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - #if 0 the following unused global functions:
> - hpsb_lock
> - hpsb_send_gasp
> - ieee1394_transactions.h: remove the stale hpsb_lock64 prototype
I also removed the
On Sun, Apr 17, 2005 at 10:14:24PM +0200, Adrian Bunk wrote:
> The options CONFIG_IEEE1394_PCILYNX_LOCALRAM and
> CONFIG_IEEE1394_PCILYNX_PORTS are not available for some time.
>
> Is this patch for removing them and the code behind them correct, or is
> a future usage planned?
I don't see a
On Sat, Apr 16, 2005 at 05:55:19PM +0200, Jesper Juhl wrote:
> This patch removes redundant NULL pointer checks before kfree() in all of
> drivers/ieee1394/
Thanks, applied to our SVN and queued for 2.6.13.
Jody
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
>
>
On Sat, Apr 16, 2005 at 05:55:19PM +0200, Jesper Juhl wrote:
This patch removes redundant NULL pointer checks before kfree() in all of
drivers/ieee1394/
Thanks, applied to our SVN and queued for 2.6.13.
Jody
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/ieee1394/nodemgr.c
On Sun, Apr 17, 2005 at 10:14:24PM +0200, Adrian Bunk wrote:
The options CONFIG_IEEE1394_PCILYNX_LOCALRAM and
CONFIG_IEEE1394_PCILYNX_PORTS are not available for some time.
Is this patch for removing them and the code behind them correct, or is
a future usage planned?
I don't see a use
On Tue, Apr 19, 2005 at 02:45:23AM +0200, Adrian Bunk wrote:
This patch contains the following possible cleanups:
- #if 0 the following unused global functions:
- hpsb_lock
- hpsb_send_gasp
- ieee1394_transactions.h: remove the stale hpsb_lock64 prototype
I also removed the EXPORT_SYMBOL
On Sun, Apr 17, 2005 at 09:57:07PM +0200, Adrian Bunk wrote:
> This patch removes unneeded EXPORT_SYMBOL's.
Didn't you already send something like this (with fewer removals, mind
you) in December?
http://marc.theaimsgroup.com/?l=linux1394-devel=110350765817261=2
Given the objections to your
Convert XFS to use sem_getcount instead of nasty hack. Fixes warning
with XFS debugging on parisc (untested since I can't find an obvious way
to enable XFS debugging) as well as the valusema macro, used in two places
in XFS.
Tested on i386, ia64, parisc.
Signed-off-by: Jody McIntyre <[EM
Convert 1394's node manager to use sem_getcount instead of nasty hack.
Tested on parisc (where it eliminates a warning), ia64, i386.
Signed-off-by: Jody McIntyre <[EMAIL PROTECTED]>
Index: 1394-dev/drivers/ieee1394/nod
Adds sem_getcount() to architectures that were missing it. Renames
sema_count on arm for this purpose (sema_count has no current callers.)
Tested on i386, ia64, parisc.
Signed-off-by: Jody McIntyre <[EMAIL PROTECTED]>
Index: 1394-dev/include/asm-h8300/semap
Adds sem_getcount() to architectures that were missing it. Renames
sema_count on arm for this purpose (sema_count has no current callers.)
Tested on i386, ia64, parisc.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/include/asm-h8300/semaphore.h
Convert 1394's node manager to use sem_getcount instead of nasty hack.
Tested on parisc (where it eliminates a warning), ia64, i386.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/drivers/ieee1394/nodemgr.c
Convert XFS to use sem_getcount instead of nasty hack. Fixes warning
with XFS debugging on parisc (untested since I can't find an obvious way
to enable XFS debugging) as well as the valusema macro, used in two places
in XFS.
Tested on i386, ia64, parisc.
Signed-off-by: Jody McIntyre [EMAIL
On Fri, Mar 11, 2005 at 12:27:47PM +, Matthew Wilcox wrote:
> > But I guess it's a bit hard to justify adding more infrastructure to
> > support a single callsite which has a simple alternative. So if you could
> > please add the separate counter?
>
> It's pretty *small* infrastructure, and
On Fri, Mar 11, 2005 at 12:27:47PM +, Matthew Wilcox wrote:
But I guess it's a bit hard to justify adding more infrastructure to
support a single callsite which has a simple alternative. So if you could
please add the separate counter?
It's pretty *small* infrastructure, and it
On Thu, Mar 10, 2005 at 08:55:03PM -0800, Andrew Morton wrote:
> Jody McIntyre <[EMAIL PROTECTED]> wrote:
> >
> > parisc and frv define sem_getcount() in semaphore.h, which returns the
> > current semaphore value. This is cleaner than doing
> > atomic_read(
no current callers.)
Tested on i386, ia64, parisc.
Signed-off-by: Jody McIntyre <[EMAIL PROTECTED]>
Index: 1394-dev/include/asm-h8300/semaphore.h
===
--- 1394-dev.orig/include/asm-h8300/semaphore.h 2005-02-10 12:39:28.0
Convert 1394's node manager to use sem_getcount instead of nasty hack.
Tested on parisc (where it eliminates a warning), ia64, i386.
Signed-off-by: Jody McIntyre <[EMAIL PROTECTED]>
Index: 1394-dev/drivers/ieee1394/nod
Convert XFS to use sem_getcount instead of nasty hack. Should fix warning
with XFS debugging on PARISC. Untested since there is no obvious way to
turn on XFS debugging.
Signed-off-by: Jody McIntyre <[EMAIL PROTECTED]>
Index: 1394-dev/fs/xfs/linux-2.6/xfs
Convert XFS to use sem_getcount instead of nasty hack. Should fix warning
with XFS debugging on PARISC. Untested since there is no obvious way to
turn on XFS debugging.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/fs/xfs/linux-2.6/xfs_buf.c
Convert 1394's node manager to use sem_getcount instead of nasty hack.
Tested on parisc (where it eliminates a warning), ia64, i386.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/drivers/ieee1394/nodemgr.c
(sema_count has no current callers.)
Tested on i386, ia64, parisc.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/include/asm-h8300/semaphore.h
===
--- 1394-dev.orig/include/asm-h8300/semaphore.h 2005-02-10 12:39
On Thu, Mar 10, 2005 at 08:55:03PM -0800, Andrew Morton wrote:
Jody McIntyre [EMAIL PROTECTED] wrote:
parisc and frv define sem_getcount() in semaphore.h, which returns the
current semaphore value. This is cleaner than doing
atomic_read(semaphore.count), currently done in
drivers
On Thu, Mar 03, 2005 at 11:55:09PM +0100, Panagiotis Issaris wrote:
> Adds the missing failure handling for a __copy_to_user call.
>
>
> Signed-off-by: Panagiotis Issaris <[EMAIL PROTECTED]>
Sorry I didn't notice this sooner, but this was already fixed and has
been sent to Linus (hopefully to
On Thu, Mar 03, 2005 at 11:55:09PM +0100, Panagiotis Issaris wrote:
Adds the missing failure handling for a __copy_to_user call.
Signed-off-by: Panagiotis Issaris [EMAIL PROTECTED]
Sorry I didn't notice this sooner, but this was already fixed and has
been sent to Linus (hopefully to appear
> Thanks. Here's my third try :-)
>
> With friendly regards,
> Takis
I'll apply this to the 1394 tree and send it to Linus after testing if
you add a Signed-off-by: line per Documentation/SubmittingPatches .
Also, please cc [EMAIL PROTECTED] with ieee1394
changes.
Thanks,
Jody
>
> --
>
Thanks. Here's my third try :-)
With friendly regards,
Takis
I'll apply this to the 1394 tree and send it to Linus after testing if
you add a Signed-off-by: line per Documentation/SubmittingPatches .
Also, please cc [EMAIL PROTECTED] with ieee1394
changes.
Thanks,
Jody
--
K.U.Leuven,
On Sat, Feb 19, 2005 at 11:36:05AM -0800, David Brownell wrote:
>
> Those allocations could be from _using_ a dma pool ... but they're
> not from just creating one!
>
> The cost of creating the dma_pool is the cost of one small kmalloc()
> plus (the expensive part) the /sys/devices/.../pools
On Sat, Feb 19, 2005 at 11:36:05AM -0800, David Brownell wrote:
Those allocations could be from _using_ a dma pool ... but they're
not from just creating one!
The cost of creating the dma_pool is the cost of one small kmalloc()
plus (the expensive part) the /sys/devices/.../pools sysfs
On Fri, Feb 18, 2005 at 10:42:46AM -0500, Parag Warudkar wrote:
> On Friday 18 February 2005 10:32 am, Dan Dennedy wrote:
> > I have tested the patches (including for allocation), and it is working
> > great, but should I only commit for now the deallocation patch? Hmm..
> > which is worse the
On Fri, Feb 18, 2005 at 10:42:46AM -0500, Parag Warudkar wrote:
On Friday 18 February 2005 10:32 am, Dan Dennedy wrote:
I have tested the patches (including for allocation), and it is working
great, but should I only commit for now the deallocation patch? Hmm..
which is worse the debug or
On Tue, Feb 15, 2005 at 01:47:59AM +0100, Pavel Machek wrote:
> Hi!
>
> This should fix u32 vs. pm_message_t confusion in firewire. No code
> changes. Please apply,
> Pavel
Applied to 1394 SVN and development bitkeeper. I will send this
On Tue, Feb 15, 2005 at 01:47:59AM +0100, Pavel Machek wrote:
Hi!
This should fix u32 vs. pm_message_t confusion in firewire. No code
changes. Please apply,
Pavel
Applied to 1394 SVN and development bitkeeper. I will send this
upstream
On Thu, Jan 20, 2005 at 01:23:47PM -0700, Trever L. Adams wrote:
> By bridge chips I mean IEEE-1394 to IDE. Also, is it possible to set
> spin down time for these IDE disks through 1394? i.e. if they are
> inactive for 1 hour, I would like them to spin down. Is this possible?
Not currently. I'm
On Thu, Jan 20, 2005 at 01:23:47PM -0700, Trever L. Adams wrote:
By bridge chips I mean IEEE-1394 to IDE. Also, is it possible to set
spin down time for these IDE disks through 1394? i.e. if they are
inactive for 1 hour, I would like them to spin down. Is this possible?
Not currently. I'm not
On Fri, Feb 11, 2005 at 10:35:33AM -0500, Dan Dennedy wrote:
> I am testing this patch in the same manner as you: exiting Kino capture.
> I am getting a similar error in a different location. Can you look into
> it, please?
>
> Debug: sleeping function called from invalid context at
On Fri, Feb 11, 2005 at 10:35:33AM -0500, Dan Dennedy wrote:
I am testing this patch in the same manner as you: exiting Kino capture.
I am getting a similar error in a different location. Can you look into
it, please?
Debug: sleeping function called from invalid context at mm/slab.c:2082
N_ERR, dev->name, "IEEE-1394 IPv4 over 1394 Ethernet
> (fw-host%d)\n",
> + ETH1394_PRINT (KERN_INFO, dev->name, "IEEE-1394 IPv4 over 1394 Ethernet
> (fw-host%d)\n",
> host->id);
>
> hi->host = host;
Change the initialization
, IEEE-1394 IPv4 over 1394 Ethernet
(fw-host%d)\n,
host-id);
hi-host = host;
Change the initialization message for eth1394 to KERN_INFO, requested by
Steffen Zieger [EMAIL PROTECTED]
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: ieee1394/eth1394.c
On Thu, Jan 20, 2005 at 12:53:32PM -0700, Trever L. Adams wrote:
> I have a few questions: How stable is firewire (running at 800Mbps or
> faster, if any is available yet)? How stable is the Linux subsystem,
> especially for firewire disks? Is there any particularly 800Mbps bridge
> chips that
On Thu, Jan 20, 2005 at 12:53:32PM -0700, Trever L. Adams wrote:
I have a few questions: How stable is firewire (running at 800Mbps or
faster, if any is available yet)? How stable is the Linux subsystem,
especially for firewire disks? Is there any particularly 800Mbps bridge
chips that should
On Mon, Jan 17, 2005 at 11:16:05AM +, Mark Watts wrote:
>
> LaCie sell the following FireWire 800 card:
> http://www.lacie.com/uk/products/product.htm?pid=10173
>
> According to the manual, it conforms to both the OHCI and EHCI specs.
>
> Does this card work out of the box with the standard
On Mon, Jan 17, 2005 at 11:16:05AM +, Mark Watts wrote:
LaCie sell the following FireWire 800 card:
http://www.lacie.com/uk/products/product.htm?pid=10173
According to the manual, it conforms to both the OHCI and EHCI specs.
Does this card work out of the box with the standard Linux
45 matches
Mail list logo
