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
T
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_SY
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 us
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/no
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&m=110350765817261&w=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 &l
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/ieee139
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
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 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(&am
pose (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-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/ieee139
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
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 a
> 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.L
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 sysf
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 debu
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
upstr
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 n
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:208
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
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 shou
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
23 matches
Mail list logo
