Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
On Sunday 20 May 2007 08:28, Stefan Richter wrote:
> Arnd Bergmann wrote:
> > On Sunday 20 May 2007, Stefan Richter wrote:
> >>> Note that this data structure only needs conversion on x86_64 and ia64,
but
> >>> not on powerpc and other 64 bit architectures that align __u64 also in
> >>> 32 bit mode.
> >> Is this conversion just unnecessary or actually harmful on ppc64 and
others?
> >
> > With the current patch, the compat_ioctl function does not handle the
ppc32
> > version of the structure at all, so it's broken there, it would at least
> > need a
> >
> > case RAW1394_IOC_GET_CYCLE_TIMER:
> > err = raw1394_ioctl(NULL, file, cmd, arg);
> > break;
>
> Dan,
>
> maybe we should change
>
> /* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
> struct raw1394_cycle_timer {
> /* contents of Isochronous Cycle Timer register,
> as in OHCI 1.1 clause 5.13 (also with non-OHCI hosts) */
> __u32 cycle_timer;
>
> /* local time in microseconds since Epoch,
> simultaneously read with cycle timer */
> __u64 local_time;
> };
>
> to
>
> /* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
> struct raw1394_cycle_timer {
> /*
>* least significant 32 bits are contents of Isochronous Cycle
>* Timer register, as in OHCI 1.1 clause 5.13 (also with
>* non-OHCI hosts)
>*/
> __u64 cycle_timer;
>
> /*
>* local time in microseconds since Epoch,
>* simultaneously read with cycle timer
>*/
> __u64 local_time;
> };
>
> before a libraw1394 with get-cycle-timer support is released.
> Shall I prepare according patches for raw1394 and libraw1394?
This seems like a good idea, and I have forwarded it to the ffado (formerly
freebob) developers, specifically Pieter Palmers--the submitter of
raw1394_read_cycle_timer--to get his feedback.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
On Sunday 20 May 2007 08:28, Stefan Richter wrote:
Arnd Bergmann wrote:
On Sunday 20 May 2007, Stefan Richter wrote:
Note that this data structure only needs conversion on x86_64 and ia64,
but
not on powerpc and other 64 bit architectures that align __u64 also in
32 bit mode.
Is this conversion just unnecessary or actually harmful on ppc64 and
others?
With the current patch, the compat_ioctl function does not handle the
ppc32
version of the structure at all, so it's broken there, it would at least
need a
case RAW1394_IOC_GET_CYCLE_TIMER:
err = raw1394_ioctl(NULL, file, cmd, arg);
break;
Dan,
maybe we should change
/* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
struct raw1394_cycle_timer {
/* contents of Isochronous Cycle Timer register,
as in OHCI 1.1 clause 5.13 (also with non-OHCI hosts) */
__u32 cycle_timer;
/* local time in microseconds since Epoch,
simultaneously read with cycle timer */
__u64 local_time;
};
to
/* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
struct raw1394_cycle_timer {
/*
* least significant 32 bits are contents of Isochronous Cycle
* Timer register, as in OHCI 1.1 clause 5.13 (also with
* non-OHCI hosts)
*/
__u64 cycle_timer;
/*
* local time in microseconds since Epoch,
* simultaneously read with cycle timer
*/
__u64 local_time;
};
before a libraw1394 with get-cycle-timer support is released.
Shall I prepare according patches for raw1394 and libraw1394?
This seems like a good idea, and I have forwarded it to the ffado (formerly
freebob) developers, specifically Pieter Palmers--the submitter of
raw1394_read_cycle_timer--to get his feedback.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
On Sunday 06 May 2007 19:14, Petr Vandrovec wrote:
> Hello Dan,
>
> This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to
> 32bit
> applications running on 64bit kernel (tested on i386 app using x86_64
> kernel). I
> had to make following changes:
>
> * read() always failed with -EFAULT. This was happening due to
> raw1394_compat_read copying data to wrong location - access_ok always
> failed as 'r' is kernel address, not user. Whole function just tried to
> copy data from 'r' to 'r', which is not good.
>
> * write(fd, buf, 52) from 32bit app was returning 56. Most of callers did not
> care, but some (arm registration) did, and anyway it looks bad if request
> for
> writing 52 bytes returns 56. And returning sizeof anything in 'int' is not
> good as well. So all functions now return '0' instead of
> sizeof(struct raw1394_request) on success, and write() itself provides
> correct
> return value (it just returns value it was asked to write on success as
> raw1394
> does not do any partial writes at all).
>
> * Related to this was problem that write() could have returned 0 when kernel
> state would become corrupted and moved to different state than
> opened/initialized/connected. Now it returns -EBADFD which seemed
> appropriate.
>
> * And add compat_ioctl. Although all structures are more or less same,
> raw1394_iso_packets got pointer inside, and raw1394_cycle_timer got unwanted
> padding in the middle. I did not add any translation for ioctls passing
> array
> of integers around as integers seem to have same size (32 bits) on all
> architectures supported by Linux.
>
> With this in place I was able to run my test app and grab some mpegs, so I
> believe
> that I got everything necessary done. If you believe I have missed some
> ioctl, yell
> at me.
> Thanks,
> Petr Vandrovec
>
> Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
Reviewed and been testing out fine here on i386.
Acked-by: Dan Dennedy <[EMAIL PROTECTED]>
> diff -uprdN linux/drivers/ieee1394/raw1394.c linux/drivers/ieee1394/raw1394.c
> --- linux/drivers/ieee1394/raw1394.c 2007-05-06 17:45:47.0 -0700
> +++ linux/drivers/ieee1394/raw1394.c 2007-05-06 18:08:05.0 -0700
> @@ -460,7 +460,7 @@ static const char __user *raw1394_compat
> static int
> raw1394_compat_read(const char __user *buf, struct raw1394_request *r)
> {
> - struct compat_raw1394_req __user *cr = (typeof(cr)) r;
> + struct compat_raw1394_req __user *cr = (typeof(cr)) buf;
> if (!access_ok(VERIFY_WRITE, cr, sizeof(struct compat_raw1394_req)) ||
> P(type) ||
> P(error) ||
> @@ -588,7 +588,7 @@ static int state_opened(struct file_info
>
> req->req.length = 0;
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> static int state_initialized(struct file_info *fi, struct pending_request
> *req)
> @@ -602,7 +602,7 @@ static int state_initialized(struct file
> req->req.generation = atomic_read(_generation);
> req->req.length = 0;
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> switch (req->req.type) {
> @@ -674,7 +674,7 @@ out_set_card:
> }
>
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> static void handle_iso_listen(struct file_info *fi, struct pending_request
> *req)
> @@ -866,7 +866,7 @@ static int handle_async_request(struct f
> if (req->req.error) {
> req->req.length = 0;
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> hpsb_set_packet_complete_task(packet,
> @@ -884,7 +884,7 @@ static int handle_async_request(struct f
> hpsb_free_tlabel(packet);
> queue_complete_req(req);
> }
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> static int handle_iso_send(struct file_info *fi, struct pending_request *req,
> @@ -908,7 +908,7 @@ static int handle_iso_send(struct file_i
> req->req.error = RAW1394_ERROR_MEMFAULT;
> req->req.length = 0;
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> req->req.length = 0;
> @@ -928,7 +928,7
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
On Sunday 06 May 2007 19:14, Petr Vandrovec wrote:
Hello Dan,
This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to
32bit
applications running on 64bit kernel (tested on i386 app using x86_64
kernel). I
had to make following changes:
* read() always failed with -EFAULT. This was happening due to
raw1394_compat_read copying data to wrong location - access_ok always
failed as 'r' is kernel address, not user. Whole function just tried to
copy data from 'r' to 'r', which is not good.
* write(fd, buf, 52) from 32bit app was returning 56. Most of callers did not
care, but some (arm registration) did, and anyway it looks bad if request
for
writing 52 bytes returns 56. And returning sizeof anything in 'int' is not
good as well. So all functions now return '0' instead of
sizeof(struct raw1394_request) on success, and write() itself provides
correct
return value (it just returns value it was asked to write on success as
raw1394
does not do any partial writes at all).
* Related to this was problem that write() could have returned 0 when kernel
state would become corrupted and moved to different state than
opened/initialized/connected. Now it returns -EBADFD which seemed
appropriate.
* And add compat_ioctl. Although all structures are more or less same,
raw1394_iso_packets got pointer inside, and raw1394_cycle_timer got unwanted
padding in the middle. I did not add any translation for ioctls passing
array
of integers around as integers seem to have same size (32 bits) on all
architectures supported by Linux.
With this in place I was able to run my test app and grab some mpegs, so I
believe
that I got everything necessary done. If you believe I have missed some
ioctl, yell
at me.
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
Reviewed and been testing out fine here on i386.
Acked-by: Dan Dennedy [EMAIL PROTECTED]
diff -uprdN linux/drivers/ieee1394/raw1394.c linux/drivers/ieee1394/raw1394.c
--- linux/drivers/ieee1394/raw1394.c 2007-05-06 17:45:47.0 -0700
+++ linux/drivers/ieee1394/raw1394.c 2007-05-06 18:08:05.0 -0700
@@ -460,7 +460,7 @@ static const char __user *raw1394_compat
static int
raw1394_compat_read(const char __user *buf, struct raw1394_request *r)
{
- struct compat_raw1394_req __user *cr = (typeof(cr)) r;
+ struct compat_raw1394_req __user *cr = (typeof(cr)) buf;
if (!access_ok(VERIFY_WRITE, cr, sizeof(struct compat_raw1394_req)) ||
P(type) ||
P(error) ||
@@ -588,7 +588,7 @@ static int state_opened(struct file_info
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
static int state_initialized(struct file_info *fi, struct pending_request
*req)
@@ -602,7 +602,7 @@ static int state_initialized(struct file
req-req.generation = atomic_read(internal_generation);
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
switch (req-req.type) {
@@ -674,7 +674,7 @@ out_set_card:
}
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
static void handle_iso_listen(struct file_info *fi, struct pending_request
*req)
@@ -866,7 +866,7 @@ static int handle_async_request(struct f
if (req-req.error) {
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
hpsb_set_packet_complete_task(packet,
@@ -884,7 +884,7 @@ static int handle_async_request(struct f
hpsb_free_tlabel(packet);
queue_complete_req(req);
}
- return sizeof(struct raw1394_request);
+ return 0;
}
static int handle_iso_send(struct file_info *fi, struct pending_request *req,
@@ -908,7 +908,7 @@ static int handle_iso_send(struct file_i
req-req.error = RAW1394_ERROR_MEMFAULT;
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
req-req.length = 0;
@@ -928,7 +928,7 @@ static int handle_iso_send(struct file_i
queue_complete_req(req);
}
- return sizeof(struct raw1394_request);
+ return 0;
}
static int handle_async_send(struct file_info *fi, struct pending_request
*req)
@@ -943,7 +943,7 @@ static int handle_async_send(struct file
req-req.error = RAW1394_ERROR_INVALID_ARG;
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request
Re: [2.6 patch] drivers/ieee1394/: remove unneeded EXPORT_SYMBOL's
On Wed, 2005-04-20 at 18:31 +0200, Stefan Richter wrote: > Arjan van de Ven wrote: > > On Wed, 2005-04-20 at 00:00 +0200, Stefan Richter wrote: > >>There are users (though not in "the" kernel at the moment) > > nor for the last 5 months... how long will it be ? > > Have there been problems with the API during the past 5 months, except > that several kernel trees are using some parts of the API? (We are > actually speaking about two APIs of the ieee1394 framework.) > > Which problems are solved by this patch? Do they outweigh the problems > it creates? The latter have been discussed. Dismissing them as Other > People's Problems does not nullify them. > > Where is the agreed-upon, published plan for removal of features in > ieee1394? Of course, there is none. In an unofficial capacity, there is just the opinion and votes of the subsystem maintainers, extended team (e.g., Stefan and me), and kernel maintainers (Linus, Andrew, and Marcello). The users are represented by the subsystem maintainers and extended team. So, Arjan's opinion does not matter except to offer some voice of reason. I think I was first to raise objection upon the initial submission some months back, and then I just observed the dialog. There are technical merits for removal of the external symbols that I accept. I also accept that we have no way of maintaining any sort of stable subsystem for external projects we are not aware of or who are not communicating with us about their requirements (it goes beyond just a stable interface). Based upon my experience of several years on this project there is only one external kernel module project we need to consider because that developer has been involved and voiced requirements. That is Arne Caspari's (The Imaging Source) DFG/1394 driver. I vote to remove external symbols not used by the Linux1394.org modules or the module at http://sourceforge.net/projects/video-2-1394/ Of course, I may be voted down, but I ask the others to be realistic about what we are arguing for (i.e. just being defensive?) and consider the fact that there are valid reasons for their removal. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/ieee1394/: remove unneeded EXPORT_SYMBOL's
On Wed, 2005-04-20 at 18:31 +0200, Stefan Richter wrote: Arjan van de Ven wrote: On Wed, 2005-04-20 at 00:00 +0200, Stefan Richter wrote: There are users (though not in the kernel at the moment) nor for the last 5 months... how long will it be ? Have there been problems with the API during the past 5 months, except that several kernel trees are using some parts of the API? (We are actually speaking about two APIs of the ieee1394 framework.) Which problems are solved by this patch? Do they outweigh the problems it creates? The latter have been discussed. Dismissing them as Other People's Problems does not nullify them. Where is the agreed-upon, published plan for removal of features in ieee1394? Of course, there is none. In an unofficial capacity, there is just the opinion and votes of the subsystem maintainers, extended team (e.g., Stefan and me), and kernel maintainers (Linus, Andrew, and Marcello). The users are represented by the subsystem maintainers and extended team. So, Arjan's opinion does not matter except to offer some voice of reason. I think I was first to raise objection upon the initial submission some months back, and then I just observed the dialog. There are technical merits for removal of the external symbols that I accept. I also accept that we have no way of maintaining any sort of stable subsystem for external projects we are not aware of or who are not communicating with us about their requirements (it goes beyond just a stable interface). Based upon my experience of several years on this project there is only one external kernel module project we need to consider because that developer has been involved and voiced requirements. That is Arne Caspari's (The Imaging Source) DFG/1394 driver. I vote to remove external symbols not used by the Linux1394.org modules or the module at http://sourceforge.net/projects/video-2-1394/ Of course, I may be voted down, but I ask the others to be realistic about what we are arguing for (i.e. just being defensive?) and consider the fact that there are valid reasons for their removal. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()
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 the 200K waste? On Fri, 2005-02-11 at 22:54 -0500, Parag Warudkar wrote: > Jody, > This happens every time you connect a device which ends up doing > ISO_LISTEN_CHANNEL. We fixed the device disconnect case in -mm recently. > > I had sent you and Andrew an alternative patch which fixes this > dma_pool_create case as well as the dma_pool_destroy case, albeit with a > disadvantage - The patch does pre-allocation of the IR Legacy DMA in > _pci_probe and deallocates it in _pci_remove. However I am not truly > happy with it since it possibly wastes 200K of memory for people who > don't have devices which need it. > > As I said earlier, I think the way to fix this is via schedule_work > similar to the disconnect case, but it involves good amount of code > change. I am working on it - any better ideas most welcome. > > Dan - Can you try the attached patch - on top current -mm1? (It's pretty > no brainer that it will fix both cases but two testing heads are better > than one.. :) > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() irqs_disabled()
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 the 200K waste? On Fri, 2005-02-11 at 22:54 -0500, Parag Warudkar wrote: Jody, This happens every time you connect a device which ends up doing ISO_LISTEN_CHANNEL. We fixed the device disconnect case in -mm recently. I had sent you and Andrew an alternative patch which fixes this dma_pool_create case as well as the dma_pool_destroy case, albeit with a disadvantage - The patch does pre-allocation of the IR Legacy DMA in _pci_probe and deallocates it in _pci_remove. However I am not truly happy with it since it possibly wastes 200K of memory for people who don't have devices which need it. As I said earlier, I think the way to fix this is via schedule_work similar to the disconnect case, but it involves good amount of code change. I am working on it - any better ideas most welcome. Dan - Can you try the attached patch - on top current -mm1? (It's pretty no brainer that it will fix both cases but two testing heads are better than one.. :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()
On Sun, 2005-01-30 at 20:19 -0500, Parag Warudkar wrote: > Attached is the reworked patch to take care of Andrew's suggestions - > > 1) Allocate the work struct dynamically in struct ti_ohci during device > probe, free it during device remove > 2) In ohci1394_pci_remove, ensure queued work, if any, is flushed before > the device is removed (As I understand, this should work for both device > removal cases as well as module removal - correct?) > 3) Rework the free_dma_rcv_ctx - It is called in multiple contexts by > different callers - teach it to free the dma according to caller's wish > - either direct free where caller determines the context is safe to > sleep OR delayed via schedule_work when caller wants to call it from a > context where it cannot sleep. So it now takes 2 extra arguments - > method to free - direct or delayed and if it is to be freed delayed, an > appropriate work_struct. > > Andrew - flush_scheduled_work does not touch work which isn't shceduled > - so I don't think INIT_WORK in setup is necessary. Let me know if I am > missing something here. (I tried INIT_WORK in ochi1394_pci_probe and > putting flush_scheduled_work in ohci1394_pci_remove - It did not result > in calling the work function after I did rmmod, since it wasn't scheduled.) > 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 in_atomic():1, irqs_disabled():1 [] __might_sleep+0xa1/0xc0 [] kmem_cache_alloc+0x64/0x80 [] dma_pool_create+0x7b/0x190 [] alloc_dma_rcv_ctx+0x1a2/0x400 [ohci1394] [] ohci_devctl+0x3d9/0x640 [ohci1394] [] handle_iso_listen+0xee/0x160 [raw1394] [] state_connected+0x2de/0x2f0 [raw1394] [] raw1394_write+0xae/0xe0 [raw1394] [] vfs_write+0x14c/0x160 [] sys_write+0x51/0x80 [] sysenter_past_esp+0x52/0x75 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() irqs_disabled()
On Sun, 2005-01-30 at 20:19 -0500, Parag Warudkar wrote: Attached is the reworked patch to take care of Andrew's suggestions - 1) Allocate the work struct dynamically in struct ti_ohci during device probe, free it during device remove 2) In ohci1394_pci_remove, ensure queued work, if any, is flushed before the device is removed (As I understand, this should work for both device removal cases as well as module removal - correct?) 3) Rework the free_dma_rcv_ctx - It is called in multiple contexts by different callers - teach it to free the dma according to caller's wish - either direct free where caller determines the context is safe to sleep OR delayed via schedule_work when caller wants to call it from a context where it cannot sleep. So it now takes 2 extra arguments - method to free - direct or delayed and if it is to be freed delayed, an appropriate work_struct. Andrew - flush_scheduled_work does not touch work which isn't shceduled - so I don't think INIT_WORK in setup is necessary. Let me know if I am missing something here. (I tried INIT_WORK in ochi1394_pci_probe and putting flush_scheduled_work in ohci1394_pci_remove - It did not result in calling the work function after I did rmmod, since it wasn't scheduled.) 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 in_atomic():1, irqs_disabled():1 [c0119eb1] __might_sleep+0xa1/0xc0 [c0144914] kmem_cache_alloc+0x64/0x80 [c037f07b] dma_pool_create+0x7b/0x190 [e09ede32] alloc_dma_rcv_ctx+0x1a2/0x400 [ohci1394] [e09eb239] ohci_devctl+0x3d9/0x640 [ohci1394] [e0bc5d4e] handle_iso_listen+0xee/0x160 [raw1394] [e0bc878e] state_connected+0x2de/0x2f0 [raw1394] [e0bc884e] raw1394_write+0xae/0xe0 [raw1394] [c015c80c] vfs_write+0x14c/0x160 [c015c8f1] sys_write+0x51/0x80 [c0102a39] sysenter_past_esp+0x52/0x75 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] eth1394: Change KERN_ERR to KERN_INFO
Committed On Fri, 2005-02-04 at 14:00 -0500, Jody McIntyre wrote: > Change the initialization message for eth1394 to KERN_INFO, requested > by > Steffen Zieger <[EMAIL PROTECTED]> > > Signed-off-by: Jody McIntyre <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] eth1394: Change KERN_ERR to KERN_INFO
Committed On Fri, 2005-02-04 at 14:00 -0500, Jody McIntyre wrote: Change the initialization message for eth1394 to KERN_INFO, requested by Steffen Zieger [EMAIL PROTECTED] Signed-off-by: Jody McIntyre [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
