Re: System suspend states and device driver suspend() callback
在 2013-8-16，下午7:22，"Rafael J. Wysocki" 写道： > On Friday, August 16, 2013 04:06:26 PM Li Yang wrote: >> Hi Guys, >> >> Is there a standard way for the device drivers to know if the system >> is going to “standby” mode or “mem” mode when the suspend() callbacks >> are called? > > No, there's none. > > What do you need that for? Some chips like ours are putting the on-chip devices into different low power states when entering different system low power states. When we enter system standby, on-chip devices are clock gated. While entering suspend to ram, on-chip devices are power gated. We want to driver to act differently too when entering different suspend states. - Leo > > Rafael > >
Re: System suspend states and device driver suspend() callback
在 2013-8-16，下午7:22，Rafael J. Wysocki r...@sisk.pl 写道： On Friday, August 16, 2013 04:06:26 PM Li Yang wrote: Hi Guys, Is there a standard way for the device drivers to know if the system is going to “standby” mode or “mem” mode when the suspend() callbacks are called? No, there's none. What do you need that for? Some chips like ours are putting the on-chip devices into different low power states when entering different system low power states. When we enter system standby, on-chip devices are clock gated. While entering suspend to ram, on-chip devices are power gated. We want to driver to act differently too when entering different suspend states. - Leo Rafael
RE: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Saturday, October 20, 2012 1:37 AM > To: Simon Haggett > Cc: Li Yang-R58472; Felipe Balbi; Greg Kroah-Hartman; linux- > u...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; Laurent Pinchart > Subject: Re: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests > for a disabled USB endpoint on Freescale hardware > > Hi, > > On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote: > > Some gadget drivers may attempt to dequeue requests for an endpoint > > that has already been disabled. For example, in the UVC gadget driver, > > uvc_function_set_alt() will call usb_ep_disable() when alt setting 0 > > is selected. When the userspace application subsequently issues the > > VIDIOC_STREAMOFF ioctl, uvc_video_enable() invokes usb_ep_dequeue() to > ensure that all requests have been cancelled. > > bug is on uvc gadget, then. Laurent ? > > Also, fsl should be removed from the tree, I'm trying to persuade iMX > folks to use drivers/usb/chipidea instead. Besides the iMX usage, the driver is also being used by many Freescale PowerPC/Coldfire SoCs. I agree that it's ideal to move to a common driver. But it is a large task to make the chipidea driver works for all the hardware that fsl_udc had supported and been tested on. > > > For the Freescale High Speed Dual-Role USB controller, > > fsl_ep_dequeue() provides the implementation of usb_ep_dequeue(). If > > this is called for a disabled endpoint, a kernel oops will occur when > the ep->ep.desc field is dereferenced (by ep_index()). > > fsl_ep_disable() sets this field to NULL, as well as deleting all > > pending requests for the endpoint. > > > > This patch adds an additional check to fsl_ep_dequeue() to ensure that > > the endpoint has not already been disabled before attempting to dequeue > requests. > > > > Signed-off-by: Simon Haggett > > --- > > drivers/usb/gadget/fsl_udc_core.c |5 - > > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/usb/gadget/fsl_udc_core.c > > b/drivers/usb/gadget/fsl_udc_core.c > > index 6ae70cb..acd513b 100644 > > --- a/drivers/usb/gadget/fsl_udc_core.c > > +++ b/drivers/usb/gadget/fsl_udc_core.c > > @@ -955,7 +955,10 @@ static int fsl_ep_dequeue(struct usb_ep *_ep, > struct usb_request *_req) > > int ep_num, stopped, ret = 0; > > u32 epctrl; > > > > - if (!_ep || !_req) > > + /* Ensure that the ep and request are valid, and the ep is not > > +* disabled > > +*/ > > + if (!_ep || !_req || !ep->ep.desc) > > return -EINVAL; > > > > spin_lock_irqsave(>udc->lock, flags); > > -- > > 1.7.4.1 > > > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware
-Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Saturday, October 20, 2012 1:37 AM To: Simon Haggett Cc: Li Yang-R58472; Felipe Balbi; Greg Kroah-Hartman; linux- u...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; Laurent Pinchart Subject: Re: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware Hi, On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote: Some gadget drivers may attempt to dequeue requests for an endpoint that has already been disabled. For example, in the UVC gadget driver, uvc_function_set_alt() will call usb_ep_disable() when alt setting 0 is selected. When the userspace application subsequently issues the VIDIOC_STREAMOFF ioctl, uvc_video_enable() invokes usb_ep_dequeue() to ensure that all requests have been cancelled. bug is on uvc gadget, then. Laurent ? Also, fsl should be removed from the tree, I'm trying to persuade iMX folks to use drivers/usb/chipidea instead. Besides the iMX usage, the driver is also being used by many Freescale PowerPC/Coldfire SoCs. I agree that it's ideal to move to a common driver. But it is a large task to make the chipidea driver works for all the hardware that fsl_udc had supported and been tested on. For the Freescale High Speed Dual-Role USB controller, fsl_ep_dequeue() provides the implementation of usb_ep_dequeue(). If this is called for a disabled endpoint, a kernel oops will occur when the ep-ep.desc field is dereferenced (by ep_index()). fsl_ep_disable() sets this field to NULL, as well as deleting all pending requests for the endpoint. This patch adds an additional check to fsl_ep_dequeue() to ensure that the endpoint has not already been disabled before attempting to dequeue requests. Signed-off-by: Simon Haggett simon.hagg...@realvnc.com --- drivers/usb/gadget/fsl_udc_core.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c index 6ae70cb..acd513b 100644 --- a/drivers/usb/gadget/fsl_udc_core.c +++ b/drivers/usb/gadget/fsl_udc_core.c @@ -955,7 +955,10 @@ static int fsl_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req) int ep_num, stopped, ret = 0; u32 epctrl; - if (!_ep || !_req) + /* Ensure that the ep and request are valid, and the ep is not +* disabled +*/ + if (!_ep || !_req || !ep-ep.desc) return -EINVAL; spin_lock_irqsave(ep-udc-lock, flags); -- 1.7.4.1 -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V3 5/6] Avoid duplicate probe for of platform devices
> > I don't understand, why is this just showing up now? What changed to > > cause this? Couldn't that be the real problem here? > > > > The issue is showing up because we now probe devices twice. > Previously, we just probe devices once. But now we changed the way of pci > init which makes pci controllers should be probed earlier than other > devices. > So we have to probe pci nodes separately. Probe more than once is the > root > cause of this issue. > > The pci patchset I mentioned please refer to: > http://patchwork.ozlabs.org/patch/163742/ Let me try to clarify a little bit. The of platform bus normally traverse the device tree to add all the devices. The change which caused problem is that we need to probe PCIe RC devices at a earlier stage of initialization. So we added these PCIe RC devices earlier than the normal device tree traversal process. These PCIe RC devices will be scanned again during the normal traversal and cause duplicated devices being added. Our proposal is to deal with duplicated devices automatically and make it possible to scan the device tree multiple times for devices to be added. Regards, Leo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V3 5/6] Avoid duplicate probe for of platform devices
I don't understand, why is this just showing up now? What changed to cause this? Couldn't that be the real problem here? The issue is showing up because we now probe devices twice. Previously, we just probe devices once. But now we changed the way of pci init which makes pci controllers should be probed earlier than other devices. So we have to probe pci nodes separately. Probe more than once is the root cause of this issue. The pci patchset I mentioned please refer to: http://patchwork.ozlabs.org/patch/163742/ Let me try to clarify a little bit. The of platform bus normally traverse the device tree to add all the devices. The change which caused problem is that we need to probe PCIe RC devices at a earlier stage of initialization. So we added these PCIe RC devices earlier than the normal device tree traversal process. These PCIe RC devices will be scanned again during the normal traversal and cause duplicated devices being added. Our proposal is to deal with duplicated devices automatically and make it possible to scan the device tree multiple times for devices to be added. Regards, Leo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ucc_geth: add support for netpoll
> -Original Message- > From: Anton Vorontsov [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 01, 2007 5:59 AM > To: Li Yang-r58472 > Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: Re: [PATCH] ucc_geth: add support for netpoll > > On Mon, Oct 29, 2007 at 03:17:44PM +0300, Anton Vorontsov wrote: > [...] > > > Oops. The original patch happened to hit the Junk mail box. :( > > > > That one as well? http://lkml.org/lkml/2007/10/11/128 > > > > > I think > > > the patch is good to merge after the cosmetic change. I > can do it > > > in next pull request to Jeff. > > > > Ok, great. Thanks. > > I'm wondering if you missed that email again. Maybe your mail > client/server doing weird things with emails from @ru.mvista.com? No. I have explicitly add you to the whitelist. :) Please be patient, isn't this patch a new feature which can only be integrated in the merge window? Thanks. - Leo - 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] ucc_geth: add support for netpoll
-Original Message- From: Anton Vorontsov [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 5:59 AM To: Li Yang-r58472 Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH] ucc_geth: add support for netpoll On Mon, Oct 29, 2007 at 03:17:44PM +0300, Anton Vorontsov wrote: [...] Oops. The original patch happened to hit the Junk mail box. :( That one as well? http://lkml.org/lkml/2007/10/11/128 I think the patch is good to merge after the cosmetic change. I can do it in next pull request to Jeff. Ok, great. Thanks. I'm wondering if you missed that email again. Maybe your mail client/server doing weird things with emails from @ru.mvista.com? No. I have explicitly add you to the whitelist. :) Please be patient, isn't this patch a new feature which can only be integrated in the merge window? Thanks. - Leo - 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] ucc_geth: add support for netpoll
> -Original Message-
> From: Anton Vorontsov [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 27, 2007 10:38 PM
> To: Sergei Shtylyov
> Cc: Anton Vorontsov; [EMAIL PROTECTED]; Li Yang-r58472;
> linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
> Subject: Re: [PATCH] ucc_geth: add support for netpoll
>
> On Sat, Oct 27, 2007 at 05:09:51PM +0400, Sergei Shtylyov wrote:
> > Hello.
> >
> > Anton Vorontsov wrote:
> >
> > > This patch adds netpoll support for the QE UCC Gigabit Ethernet
> > > driver. The approach is very similar to the gianfar driver.
> >
> > It's rather contrarywise -- this is standard approach
> and gianfar
> > with its
> > 3 TSEC IRQs has a quite non-standard poll_controller()
> implementation.
>
> Oh.. well, right -- gianfar a bit more comlex in that regard.
>
> >
> > > Tested using netconsole.
> >
> > KGDBoE is considered a better test (I hope you've also
> tested with it).
>
> At the time of posting it was tested using netconsole only, a
> few days later it's was tested using KGDBoE also. So, it works indeed.
>
> > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> diff --git
> > > a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index
> > > 18a6f48..06807ce 100644
> > > --- a/drivers/net/ucc_geth.c
> > > +++ b/drivers/net/ucc_geth.c
> > > @@ -3691,6 +3691,22 @@ static irqreturn_t
> ucc_geth_irq_handler(int irq, void *info)
> > > return IRQ_HANDLED;
> > > }
> > >
> > > +#ifdef CONFIG_NET_POLL_CONTROLLER
> > > +/*
> > > + * Polling 'interrupt' - used by things like netconsole to send
> > > +skbs
> > > + * without having to re-enable interrupts. It's not called while
> > > + * the interrupt routine is executing.
> > > + */
> > > +static void ucc_netpoll(struct net_device *dev) {
> > > + struct ucc_geth_private *ugeth = netdev_priv(dev);
> > > +
> > > + disable_irq(ugeth->ug_info->uf_info.irq);
> > > + ucc_geth_irq_handler(ugeth->ug_info->uf_info.irq, dev);
> > > + enable_irq(ugeth->ug_info->uf_info.irq);
> >
> > Why not make it less complex (for a reader and gcc too :-) ?
>
> Yup, I'm agree here but it's too late. Again. ;-)
>
> This patch already accepted into the -mm (a week or so after
> the silence), so.. now I'd rather not bother Andrew with such
> really cosmetic changes. But if Jeff would directly apply
> modfied patch, I'll send it. ;-)
Oops. The original patch happened to hit the Junk mail box. :( I think
the patch is good to merge after the cosmetic change. I can do it in
next pull request to Jeff.
Thanks
- Leo
-
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] ucc_geth: add support for netpoll
-Original Message-
From: Anton Vorontsov [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 27, 2007 10:38 PM
To: Sergei Shtylyov
Cc: Anton Vorontsov; [EMAIL PROTECTED]; Li Yang-r58472;
linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: [PATCH] ucc_geth: add support for netpoll
On Sat, Oct 27, 2007 at 05:09:51PM +0400, Sergei Shtylyov wrote:
Hello.
Anton Vorontsov wrote:
This patch adds netpoll support for the QE UCC Gigabit Ethernet
driver. The approach is very similar to the gianfar driver.
It's rather contrarywise -- this is standard approach
and gianfar
with its
3 TSEC IRQs has a quite non-standard poll_controller()
implementation.
Oh.. well, right -- gianfar a bit more comlex in that regard.
Tested using netconsole.
KGDBoE is considered a better test (I hope you've also
tested with it).
At the time of posting it was tested using netconsole only, a
few days later it's was tested using KGDBoE also. So, it works indeed.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
diff --git
a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index
18a6f48..06807ce 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3691,6 +3691,22 @@ static irqreturn_t
ucc_geth_irq_handler(int irq, void *info)
return IRQ_HANDLED;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * Polling 'interrupt' - used by things like netconsole to send
+skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+static void ucc_netpoll(struct net_device *dev) {
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+
+ disable_irq(ugeth-ug_info-uf_info.irq);
+ ucc_geth_irq_handler(ugeth-ug_info-uf_info.irq, dev);
+ enable_irq(ugeth-ug_info-uf_info.irq);
Why not make it less complex (for a reader and gcc too :-) ?
Yup, I'm agree here but it's too late. Again. ;-)
This patch already accepted into the -mm (a week or so after
the silence), so.. now I'd rather not bother Andrew with such
really cosmetic changes. But if Jeff would directly apply
modfied patch, I'll send it. ;-)
Oops. The original patch happened to hit the Junk mail box. :( I think
the patch is good to merge after the cosmetic change. I can do it in
next pull request to Jeff.
Thanks
- Leo
-
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: i386: kernel boot fail at check_irq_resend:69
-Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dave Young > Sent: Tuesday, August 07, 2007 2:32 PM > To: [EMAIL PROTECTED] > Cc: LKML > Subject: i386: kernel boot fail at check_irq_resend:69 > > Hi, > The kernerl 2.6.23-rc1-mm2 boot fail at check_irq_resend:69 >> if (WARN_ON_ONCE(desc->handle_irq != handle_edge_irq)) >>return; Failed? It's just a kernel Badness for me, and the boot can be finished. This is a known problem, and should be fixed soon. See: http://lkml.org/lkml/2007/8/4/204 - Leo - 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: i386: kernel boot fail at check_irq_resend:69
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Young Sent: Tuesday, August 07, 2007 2:32 PM To: [EMAIL PROTECTED] Cc: LKML Subject: i386: kernel boot fail at check_irq_resend:69 Hi, The kernerl 2.6.23-rc1-mm2 boot fail at check_irq_resend:69 if (WARN_ON_ONCE(desc-handle_irq != handle_edge_irq)) return; Failed? It's just a kernel Badness for me, and the boot can be finished. This is a known problem, and should be fixed soon. See: http://lkml.org/lkml/2007/8/4/204 - Leo - 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 3/5] HOWTO: add Chinese translation ofDocumentation/HOWTO
> -Original Message- > From: Greg KH [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 19, 2007 1:01 PM > To: WANG Cong > Cc: Jesper Juhl; linux-kernel@vger.kernel.org; Li > Yang-r58472; TripleX Chung; Maggie Chen > Subject: Re: [PATCH 3/5] HOWTO: add Chinese translation > ofDocumentation/HOWTO > > On Thu, Jul 19, 2007 at 01:12:54PM +0800, WANG Cong wrote: > > > > Since these docs are not in the mainline tree yet, I don't > have a copy. > > They are there now. Thanks. - Leo - 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] Update 2.4 maintainer in document
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Willy Tarreau > Sent: Thursday, July 19, 2007 12:46 PM > To: Li Yang > Cc: linux-kernel@vger.kernel.org > Subject: Re: [PATCH] Update 2.4 maintainer in document > > On Mon, Jul 09, 2007 at 03:05:07AM +0800, Li Yang wrote: > > Update the maintainer of 2.4 kernel in > Documentations/SubmittingPatches. > > Thanks, but you should have CCed me, because I missed you > mail ;-) I'll merge it. I don't know who is responsible for maintaining the documentation. Thanks. :) - Leo - 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] Update 2.4 maintainer in document
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Willy Tarreau Sent: Thursday, July 19, 2007 12:46 PM To: Li Yang Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] Update 2.4 maintainer in document On Mon, Jul 09, 2007 at 03:05:07AM +0800, Li Yang wrote: Update the maintainer of 2.4 kernel in Documentations/SubmittingPatches. Thanks, but you should have CCed me, because I missed you mail ;-) I'll merge it. I don't know who is responsible for maintaining the documentation. Thanks. :) - Leo - 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 3/5] HOWTO: add Chinese translation ofDocumentation/HOWTO
-Original Message- From: Greg KH [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 1:01 PM To: WANG Cong Cc: Jesper Juhl; linux-kernel@vger.kernel.org; Li Yang-r58472; TripleX Chung; Maggie Chen Subject: Re: [PATCH 3/5] HOWTO: add Chinese translation ofDocumentation/HOWTO On Thu, Jul 19, 2007 at 01:12:54PM +0800, WANG Cong wrote: Since these docs are not in the mainline tree yet, I don't have a copy. They are there now. Thanks. - Leo - 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: Documentation of kernel messages (Summary)
On Thursday, July 12, 2007 2:13 AM Rob Landley wrote: > On Wednesday 11 July 2007 10:26:30 am Li Yang wrote: > > There are quite a lot kernel developers for each of the popular > > language, AFAIK. For non-popular languages, there shouldn't be > > translation available in the first place. > > I don't distinguish between "popular" and "non-popular" languages. If > somebody's willing to do the translation work, it's popular. If nobody's > willing to do the work, then even a language 1/3 of the planet's population > speaks isn't "popular" for kernel development. > > I wouldn't discourage a translator into Klingon if they were willing to keep > their translation up to date and/or it actually resulted in patches. > > > It was really a surprise when > > I post my Chinese translation on the LKML so many Chinese speakers have > > commented on the translation and encouraged the translation work. They > > are not visible as they usually don't talk too much. :) So I set up the > > Chinese kernel development maillist([EMAIL PROTECTED]), there > > will be more and more experienced kernel developer who can read and > > update the Chinese documents after they read the translated > > documentation and become kernel hacker. > > The chinese mailing list is highly cool, and my first instinct was to note it > on kernel.org/doc, but it would be better if the chinese website I already > link to notes it instead. (That way I don't have to worry about how to > spam-guard your email address. :) The benefit of a localized maillist is that patches can be reviewed and commented in native language for common problems (like style, API). > > This also highlights the need for language maintainers to help the patches go > upstream to the english list. (If we can avoid armchair commentators > saddling them with the task of translating the entire Documentation directory > and keeping such a translation up to date, we might actually get one too. > Fielding patches and questions sounds like plenty to me...) I do think the documentation translation is very necessary even when there is a language maintainer, especially for the policy documents as HOWTO, codestyle , and etc. The contributors should go through these policies and check their code for compliance before going to the language maintainer for help, or there will be too much for the language maintainer to translate. The language maintainer doesn't need to translate all the documents himself, but he can help to coordinate the translation effort and help to make it update to date. > > Could you ask on said list if anyone is likely to volunteer for the position? > (JUST translating patches and questions, as part of pushing code upstream.) If we do need a contact person, I can do it. However I don't think there will be much translation work to do here. As I stated before, most Chinese programmers are more or less capable of read/write technical English. The difficult part is to let them know the benefit of merging code in kernel and teach them how to do it. That's why the policy documents in native language will be very useful. > > > > Merging into the kernel is a great way to keep CODE up to date. Don't > > > think > > > it's magic pixie dust for documentation. It never has been before. > > > > IMHO, having contribution merged into the kernel has the MAGIC to > > attract people to work for recognition. When more and more people > > volunteer to work on it, the documentation will be up to date magically. > > Obvious counter-arguments include the floppy driver, the floppy tape driver, > the tty layer, and most of the existing english Documentation directory... > > I'll happily stay out of the way of people who actually want to merge > translations of documentation into the kernel. I reserve the right to say "I > told you so" in about five years. > > > > Ah, but It's not a language maintainer's job to update documentation. > > > It's > > > their job to ACCEPT PATCHES. Translate patches, translate questions > > > back and > > > forth. This has NOTHING to do with documentation unless they're > > > converting > > > documentation accompanying the patch one way; into english. > > > > Language maintainers can integrate updates to the documentation just > > like integrating any updates to the code. Working on the documentation > > is ,IMHO, a perfect task for novice kernel hacker to get familiar with > > the process. > > From a language maintainer's perspective documentation patches wouldn't be any > different than any other patches. Translate the description and questions > going back and forth. The patch itself doesn't get translated when it's C > and applies to scripts/kconfig/, why would it when it's UTF-8 and applies to > Documentation/? > > Of course this brings up the question "what kind of function and variable > names do chinese people pick?" (I honestly don't know, but I note that > attempts to use names that don't fit in 7-bit ascii would probably
RE: Documentation of kernel messages (Summary)
On Thursday, July 12, 2007 2:13 AM Rob Landley wrote: On Wednesday 11 July 2007 10:26:30 am Li Yang wrote: There are quite a lot kernel developers for each of the popular language, AFAIK. For non-popular languages, there shouldn't be translation available in the first place. I don't distinguish between popular and non-popular languages. If somebody's willing to do the translation work, it's popular. If nobody's willing to do the work, then even a language 1/3 of the planet's population speaks isn't popular for kernel development. I wouldn't discourage a translator into Klingon if they were willing to keep their translation up to date and/or it actually resulted in patches. It was really a surprise when I post my Chinese translation on the LKML so many Chinese speakers have commented on the translation and encouraged the translation work. They are not visible as they usually don't talk too much. :) So I set up the Chinese kernel development maillist([EMAIL PROTECTED]), there will be more and more experienced kernel developer who can read and update the Chinese documents after they read the translated documentation and become kernel hacker. The chinese mailing list is highly cool, and my first instinct was to note it on kernel.org/doc, but it would be better if the chinese website I already link to notes it instead. (That way I don't have to worry about how to spam-guard your email address. :) The benefit of a localized maillist is that patches can be reviewed and commented in native language for common problems (like style, API). This also highlights the need for language maintainers to help the patches go upstream to the english list. (If we can avoid armchair commentators saddling them with the task of translating the entire Documentation directory and keeping such a translation up to date, we might actually get one too. Fielding patches and questions sounds like plenty to me...) I do think the documentation translation is very necessary even when there is a language maintainer, especially for the policy documents as HOWTO, codestyle , and etc. The contributors should go through these policies and check their code for compliance before going to the language maintainer for help, or there will be too much for the language maintainer to translate. The language maintainer doesn't need to translate all the documents himself, but he can help to coordinate the translation effort and help to make it update to date. Could you ask on said list if anyone is likely to volunteer for the position? (JUST translating patches and questions, as part of pushing code upstream.) If we do need a contact person, I can do it. However I don't think there will be much translation work to do here. As I stated before, most Chinese programmers are more or less capable of read/write technical English. The difficult part is to let them know the benefit of merging code in kernel and teach them how to do it. That's why the policy documents in native language will be very useful. Merging into the kernel is a great way to keep CODE up to date. Don't think it's magic pixie dust for documentation. It never has been before. IMHO, having contribution merged into the kernel has the MAGIC to attract people to work for recognition. When more and more people volunteer to work on it, the documentation will be up to date magically. Obvious counter-arguments include the floppy driver, the floppy tape driver, the tty layer, and most of the existing english Documentation directory... I'll happily stay out of the way of people who actually want to merge translations of documentation into the kernel. I reserve the right to say I told you so in about five years. Ah, but It's not a language maintainer's job to update documentation. It's their job to ACCEPT PATCHES. Translate patches, translate questions back and forth. This has NOTHING to do with documentation unless they're converting documentation accompanying the patch one way; into english. Language maintainers can integrate updates to the documentation just like integrating any updates to the code. Working on the documentation is ,IMHO, a perfect task for novice kernel hacker to get familiar with the process. From a language maintainer's perspective documentation patches wouldn't be any different than any other patches. Translate the description and questions going back and forth. The patch itself doesn't get translated when it's C and applies to scripts/kconfig/, why would it when it's UTF-8 and applies to Documentation/? Of course this brings up the question what kind of function and variable names do chinese people pick? (I honestly don't know, but I note that attempts to use names that don't fit in 7-bit ascii would probably be frowned upon in a big way...) It won't be too hard if the work is shared by a community. Like the one I'm trying
RE: Documentation of kernel messages (Summary)
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rob Landley > Sent: Tuesday, July 10, 2007 12:48 AM > To: H. Peter Anvin > Cc: Kunai, Takashi; [EMAIL PROTECTED]; Andrew Morton; > linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Documentation of kernel messages (Summary) > > In regard to translating kernel messages: > > On Monday 09 July 2007 01:36:31 H. Peter Anvin wrote: > > Kunai, Takashi wrote: > > > (1) Your kernel development proposal will be greatly supported by > > > Japanese vendor community. At the same time, it needs support from the > > > kernel communities, as well. > > > > There is a very strong reason for the kernel community to NOT support > > this: it makes it much harder to deal with bug reports. > > Agreed. > > There's a proposal in play for translations of documentation, and to > recruit "language maintainers" (which is an idea I see that Matt Mackall came > up with before I did). > > A language maintainer is somebody who can accept a patch in language X, > translate its description to post on the appropriate english-only list with a > cc: to the appropriate maintainer(s), and translate questions and reviews > back and forth for the original author until the patch can be merged. (This > means that documentation translations don't result in a stream of unmergeable > patches.) > > As for the documentation translations themselves, I note that Eric Raymond > dissuaded me from actually hosting translations of kernel documentation on > http://kernel.org/doc due to his experience with translations of his own > writings. If he hosts the translations on his website, they never get > updated again. But if he makes the contributor host them on their own > website, then they sometimes get updated. If the documents are already maintained together on one site, it won't be very hard to synchronize with kernel.org. Eric is right for the case that separate documents on separate sites. > > For my part, I can't _tell_ when a given translation is out of date because I > can't read it, and I certainly can't update it. So I agree with Eric and I'm > linking to sites hosting kernel documentation in other languages rather than > hosting them myself. I've got a good link to a Japanese site, need to ping > the contributors of the chinese documentation and see if they have a site for > it... Please add a link to http://zh-kernel.org/docs for Chinese translated kernel documentation. - Leo - 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: Documentation of kernel messages (Summary)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Landley Sent: Tuesday, July 10, 2007 12:48 AM To: H. Peter Anvin Cc: Kunai, Takashi; [EMAIL PROTECTED]; Andrew Morton; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Documentation of kernel messages (Summary) In regard to translating kernel messages: On Monday 09 July 2007 01:36:31 H. Peter Anvin wrote: Kunai, Takashi wrote: (1) Your kernel development proposal will be greatly supported by Japanese vendor community. At the same time, it needs support from the kernel communities, as well. There is a very strong reason for the kernel community to NOT support this: it makes it much harder to deal with bug reports. Agreed. There's a proposal in play for translations of documentation, and to recruit language maintainers (which is an idea I see that Matt Mackall came up with before I did). A language maintainer is somebody who can accept a patch in language X, translate its description to post on the appropriate english-only list with a cc: to the appropriate maintainer(s), and translate questions and reviews back and forth for the original author until the patch can be merged. (This means that documentation translations don't result in a stream of unmergeable patches.) As for the documentation translations themselves, I note that Eric Raymond dissuaded me from actually hosting translations of kernel documentation on http://kernel.org/doc due to his experience with translations of his own writings. If he hosts the translations on his website, they never get updated again. But if he makes the contributor host them on their own website, then they sometimes get updated. If the documents are already maintained together on one site, it won't be very hard to synchronize with kernel.org. Eric is right for the case that separate documents on separate sites. For my part, I can't _tell_ when a given translation is out of date because I can't read it, and I certainly can't update it. So I agree with Eric and I'm linking to sites hosting kernel documentation in other languages rather than hosting them myself. I've got a good link to a Japanese site, need to ping the contributors of the chinese documentation and see if they have a site for it... Please add a link to http://zh-kernel.org/docs for Chinese translated kernel documentation. - Leo - 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] PXA27x UDC driver.
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo Giometti > Sent: Thursday, June 28, 2007 6:36 PM > To: [EMAIL PROTECTED] > Cc: linux-kernel@vger.kernel.org; Andrew Morton > Subject: [PATCH] PXA27x UDC driver. > > Hello, > > 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 time PXA27x has its UDC driver into linux! :) > > Thanks for your suggestions, You should probably also cc: [EMAIL PROTECTED] and David Brownell for UDC matters. - Leo - 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] CodingStyle: Add information about trailing whitespace.
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Josh Triplett > Sent: Thursday, June 28, 2007 2:59 PM > To: Jan Engelhardt > Cc: dave young; Chris Shoemaker; Josh Triplett; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: Re: [PATCH] CodingStyle: Add information about trailing whitespace. > > Jan Engelhardt wrote: > > On Jun 28 2007 06:29, dave young wrote: > >> IMHO, another cause of trailing whitespace is human error, for > >> example long lines breaking will easy to cause the first line with one > >> traling whitespace (original space between the last two words). > > > > Most common errors (to me) are: > > > > - hit return+tab too quickly that it interchanges, hence producing > >the unwanted \t\n > > - hit return+return to start a new paragraph of code; > >the intermediate line remains indented if autoindent is on. > > Interestingly, emacs gets that case right: when you hit enter it places the > cursor at the properly indented insertion point, but if you leave the line > without typing anything it does not leave the indentation. I thought I > remembered vim doing the same thing, but I just tested and it appears not. It > seems to avoid leaving subsequent lines indented, but not the first one. No, vim works just fine here without leaving any indentation. Maybe the version of vim or the options matter. - Leo - 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] CodingStyle: Add information about trailing whitespace.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Triplett Sent: Thursday, June 28, 2007 2:59 PM To: Jan Engelhardt Cc: dave young; Chris Shoemaker; Josh Triplett; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH] CodingStyle: Add information about trailing whitespace. Jan Engelhardt wrote: On Jun 28 2007 06:29, dave young wrote: IMHO, another cause of trailing whitespace is human error, for example long lines breaking will easy to cause the first line with one traling whitespace (original space between the last two words). Most common errors (to me) are: - hit return+tab too quickly that it interchanges, hence producing the unwanted \t\n - hit return+return to start a new paragraph of code; the intermediate line remains indented if autoindent is on. Interestingly, emacs gets that case right: when you hit enter it places the cursor at the properly indented insertion point, but if you leave the line without typing anything it does not leave the indentation. I thought I remembered vim doing the same thing, but I just tested and it appears not. It seems to avoid leaving subsequent lines indented, but not the first one. No, vim works just fine here without leaving any indentation. Maybe the version of vim or the options matter. - Leo - 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] PXA27x UDC driver.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo Giometti Sent: Thursday, June 28, 2007 6:36 PM To: [EMAIL PROTECTED] Cc: linux-kernel@vger.kernel.org; Andrew Morton Subject: [PATCH] PXA27x UDC driver. Hello, 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 time PXA27x has its UDC driver into linux! :) Thanks for your suggestions, You should probably also cc: [EMAIL PROTECTED] and David Brownell for UDC matters. - Leo - 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] Chinese translation of Documentation/HOWTO
> -Original Message- > From: Rob Landley [mailto:[EMAIL PROTECTED] > Sent: Friday, June 22, 2007 1:33 PM > To: dave young > Cc: Li Yang-r58472; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; TripleX Chung; Maggie Chen; > [EMAIL PROTECTED] > Subject: Re: [PATCH] Chinese translation of Documentation/HOWTO > > On Thursday 21 June 2007 23:23:54 dave young wrote: > > Hi, > > > > 2007/6/22, Rob Landley <[EMAIL PROTECTED]>: > > > On Thursday 21 June 2007 10:40:17 Li Yang wrote: > > > > This is a Chinese translated version of Documentation/HOWTO. Currently > > > > Chinese involvement in Linux kernel is very low, especially comparing > > > > to its largest population base. Language could be the main obstacle. > > > > Hope this document will help more Chinese to contribute to Linux > > > > kernel. > > > > > > I'm putting together a kernel documentation directory at > > > http://kernel.org/doc and I could easily add translations in there. I > > > just don't know if this is a good idea. > > > > I think it's not a good idea to merge translations into kernel. > > > > > The problem is, the submission of patches happens on the various > > > kernel.org mailing lists, which are all in English. Kernel development > > > is done in a single common language: English. (If you'd like to argue > > > for it to be done in another language, please make the proposal in > > > Linus's native Swedish.) > > > > Yes, I agree with you, and there's so many other languages, It's > > better for someone to create a standalone kdoc translation project > > than to merge them into kernel. > > I wasn't suggesting merging them into the kernel. > > I'm doing a web page to put together html versions of lots of kernel > documentation in a place Google can find it. Peter Anvin was kind enough to > give me http://kernel.org/doc for this. It would not be technically > difficult for this web page to host translated versions of this > documentation. > > The question is, do the kernel developers want to encourage people who don't > speak English to mess with the kernel, any more than they want to encourage > kernel developers who don't know C? Is kernel documentation in Chinese a > better idea than a repository of kernel patches in C++? (Either way, work > resulting from this is much less likely than normal to be merged into the > kernel.) IMHO, the ultimate language for the Linux kernel is C language rather than English. Nothing prevents one with poor English to write good C code except for the comment part. However if the code is really good to be understood on its own, the problem is not that important then. Moreover, the case here is not about people who can't read/write in English completely. It is to help and to encourage people who have some difficulty to deal with the community but has the basic English skill to deal with technical discussion. That's like why we have disability services for special people who can do things actually. - Leo - 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] Chinese translation of Documentation/HOWTO
-Original Message- From: Rob Landley [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 1:33 PM To: dave young Cc: Li Yang-r58472; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; TripleX Chung; Maggie Chen; [EMAIL PROTECTED] Subject: Re: [PATCH] Chinese translation of Documentation/HOWTO On Thursday 21 June 2007 23:23:54 dave young wrote: Hi, 2007/6/22, Rob Landley [EMAIL PROTECTED]: On Thursday 21 June 2007 10:40:17 Li Yang wrote: This is a Chinese translated version of Documentation/HOWTO. Currently Chinese involvement in Linux kernel is very low, especially comparing to its largest population base. Language could be the main obstacle. Hope this document will help more Chinese to contribute to Linux kernel. I'm putting together a kernel documentation directory at http://kernel.org/doc and I could easily add translations in there. I just don't know if this is a good idea. I think it's not a good idea to merge translations into kernel. The problem is, the submission of patches happens on the various kernel.org mailing lists, which are all in English. Kernel development is done in a single common language: English. (If you'd like to argue for it to be done in another language, please make the proposal in Linus's native Swedish.) Yes, I agree with you, and there's so many other languages, It's better for someone to create a standalone kdoc translation project than to merge them into kernel. I wasn't suggesting merging them into the kernel. I'm doing a web page to put together html versions of lots of kernel documentation in a place Google can find it. Peter Anvin was kind enough to give me http://kernel.org/doc for this. It would not be technically difficult for this web page to host translated versions of this documentation. The question is, do the kernel developers want to encourage people who don't speak English to mess with the kernel, any more than they want to encourage kernel developers who don't know C? Is kernel documentation in Chinese a better idea than a repository of kernel patches in C++? (Either way, work resulting from this is much less likely than normal to be merged into the kernel.) IMHO, the ultimate language for the Linux kernel is C language rather than English. Nothing prevents one with poor English to write good C code except for the comment part. However if the code is really good to be understood on its own, the problem is not that important then. Moreover, the case here is not about people who can't read/write in English completely. It is to help and to encourage people who have some difficulty to deal with the community but has the basic English skill to deal with technical discussion. That's like why we have disability services for special people who can do things actually. - Leo - 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] Chinese translation of Documentation/HOWTO
> -Original Message- > From: Rob Landley [mailto:[EMAIL PROTECTED] > Sent: Friday, June 22, 2007 10:49 AM > > On Thursday 21 June 2007 10:40:17 Li Yang wrote: > > This is a Chinese translated version of Documentation/HOWTO. Currently > > Chinese involvement in Linux kernel is very low, especially comparing to > > its largest population base. Language could be the main obstacle. Hope > > this document will help more Chinese to contribute to Linux kernel. > > I'm putting together a kernel documentation directory at http://kernel.org/doc > and I could easily add translations in there. I just don't know if this is a > good idea. > > The problem is, the submission of patches happens on the various kernel.org > mailing lists, which are all in English. Kernel development is done in a > single common language: English. (If you'd like to argue for it to be done > in another language, please make the proposal in Linus's native Swedish.) > > Setting aside for the moment version skew and coverage issues when translating > Documentation, which aren't really serious blocking issues, my question is > this: If developers aren't fluent enough with English to follow the > documentation, how can they follow any of the technical discussions necessary > to merge their patches back into the mainstream kernel? Doesn't this > encourage the creation of patches that can't easily be merged back into the > kernel? So as I argued in a previous email, non-native English speakers tend to be more confused by the policies and processes. I also don't think it's necessary to translate the technical documents. To be a software developer, one has to be educated or experienced in technical terms. Technical discussion can be done without too much requirement to grammar and emotional expressing. The translated document of policies and processes will help these people to understand the process better and go smoother in the process. - Leo - 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] Chinese translation of Documentation/HOWTO
-Original Message- From: Rob Landley [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 10:49 AM On Thursday 21 June 2007 10:40:17 Li Yang wrote: This is a Chinese translated version of Documentation/HOWTO. Currently Chinese involvement in Linux kernel is very low, especially comparing to its largest population base. Language could be the main obstacle. Hope this document will help more Chinese to contribute to Linux kernel. I'm putting together a kernel documentation directory at http://kernel.org/doc and I could easily add translations in there. I just don't know if this is a good idea. The problem is, the submission of patches happens on the various kernel.org mailing lists, which are all in English. Kernel development is done in a single common language: English. (If you'd like to argue for it to be done in another language, please make the proposal in Linus's native Swedish.) Setting aside for the moment version skew and coverage issues when translating Documentation, which aren't really serious blocking issues, my question is this: If developers aren't fluent enough with English to follow the documentation, how can they follow any of the technical discussions necessary to merge their patches back into the mainstream kernel? Doesn't this encourage the creation of patches that can't easily be merged back into the kernel? So as I argued in a previous email, non-native English speakers tend to be more confused by the policies and processes. I also don't think it's necessary to translate the technical documents. To be a software developer, one has to be educated or experienced in technical terms. Technical discussion can be done without too much requirement to grammar and emotional expressing. The translated document of policies and processes will help these people to understand the process better and go smoother in the process. - Leo - 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] Chinese translation of Documentation/HOWTO
> -Original Message- > From: dave young [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 20, 2007 9:58 AM > To: WANG Cong > Cc: Li Yang-r58472; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; TripleX Chung; > Maggie Chen; Tejun Heo; Fengguang Wu; Chen Li-jun > Subject: Re: [PATCH] Chinese translation of Documentation/HOWTO > > Hi, > IMHO, it is not very suitable for translations merging into kernel. > > first, It's impossible to be 100% accurate. It can be accurate by meaning. And it can be improved. > second, two or more language need to be synced with english one, it's > a problem in the long run. This can be done through good maintenance. I don't think it's harder than maintaining the code in kernel source tree. - Leo - 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] Chinese translation of Documentation/HOWTO
Hi Wangcong,
Thanks for your comments. Most of the comments are literal. I don't
believe all of them are necessary as language is a matter of personal
preference. :) I will consider your suggestions carefully and pick up
those which are really necessary.
- Leo
> -Original Message-
> From: WANG Cong [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 19, 2007 11:36 PM
> To: Li Yang-r58472
> Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; TripleX Chung;
Maggie Chen;
> Tejun Heo; Fengguang Wu; Chen Li-jun
> Subject: Re: [PATCH] Chinese translation of Documentation/HOWTO
>
> On Tue, Jun 19, 2007 at 10:21:03PM +0800, Li Yang wrote:
> >This is a Chinese translated version of Documentation/HOWTO.
Currently
> >Chinese involvement in Linux kernel is very low, especially comparing
to
> >its largest population base. Language could be the main obstacle.
Hope
> >this document will help more Chinese to contribute to Linux kernel.
>
> Thanks for your work!
>
> I hope people here who don't understand Chinese won't mind if I
comment the
> following patch in Chinese. ;)
>
{snip}
-
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] Chinese translation of Documentation/HOWTO
Hi all,
I hope this document can get into the kernel tree. As I read through
the discussion about Japanese translation, there are quite some
arguments that one cannot do kernel development effectively without
solid English skill. As a non-native English speaker, I would say that
it is much easier to understand technical terms and effectively discuss
technical matters. But community policies and politics are different
things. They will be very painful for one who doesn't really grasp
English well. IMHO, having these policy documents in different
languages will greatly help these non-native speakers to contribute,
hence greatly benefit the Linux kernel community itself.
- Leo
> -Original Message-
> From: Li Yang [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 19, 2007 10:21 PM
> To: linux-kernel@vger.kernel.org
> Cc: [EMAIL PROTECTED]; Li Yang-r58472; TripleX Chung; Maggie Chen
> Subject: [PATCH] Chinese translation of Documentation/HOWTO
>
> This is a Chinese translated version of Documentation/HOWTO.
Currently
> Chinese involvement in Linux kernel is very low, especially comparing
to
> its largest population base. Language could be the main obstacle.
Hope
> this document will help more Chinese to contribute to Linux kernel.
>
> Signed-off-by: Li Yang <[EMAIL PROTECTED]>
> Signed-off-by: TripleX Chung <[EMAIL PROTECTED]>
> Signed-off-by: Maggie Chen <[EMAIL PROTECTED]>
> ---
> Documentation/zh_CN/HOWTO | 534
> +
> 1 files changed, 534 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/zh_CN/HOWTO
>
> diff --git a/Documentation/zh_CN/HOWTO b/Documentation/zh_CN/HOWTO
> new file mode 100644
> index 000..27b0fe7
> --- /dev/null
> +++ b/Documentation/zh_CN/HOWTO
{snip}
-
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] Chinese translation of Documentation/HOWTO
Hi all,
I hope this document can get into the kernel tree. As I read through
the discussion about Japanese translation, there are quite some
arguments that one cannot do kernel development effectively without
solid English skill. As a non-native English speaker, I would say that
it is much easier to understand technical terms and effectively discuss
technical matters. But community policies and politics are different
things. They will be very painful for one who doesn't really grasp
English well. IMHO, having these policy documents in different
languages will greatly help these non-native speakers to contribute,
hence greatly benefit the Linux kernel community itself.
- Leo
-Original Message-
From: Li Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 19, 2007 10:21 PM
To: linux-kernel@vger.kernel.org
Cc: [EMAIL PROTECTED]; Li Yang-r58472; TripleX Chung; Maggie Chen
Subject: [PATCH] Chinese translation of Documentation/HOWTO
This is a Chinese translated version of Documentation/HOWTO.
Currently
Chinese involvement in Linux kernel is very low, especially comparing
to
its largest population base. Language could be the main obstacle.
Hope
this document will help more Chinese to contribute to Linux kernel.
Signed-off-by: Li Yang [EMAIL PROTECTED]
Signed-off-by: TripleX Chung [EMAIL PROTECTED]
Signed-off-by: Maggie Chen [EMAIL PROTECTED]
---
Documentation/zh_CN/HOWTO | 534
+
1 files changed, 534 insertions(+), 0 deletions(-)
create mode 100644 Documentation/zh_CN/HOWTO
diff --git a/Documentation/zh_CN/HOWTO b/Documentation/zh_CN/HOWTO
new file mode 100644
index 000..27b0fe7
--- /dev/null
+++ b/Documentation/zh_CN/HOWTO
{snip}
-
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] Chinese translation of Documentation/HOWTO
Hi Wangcong,
Thanks for your comments. Most of the comments are literal. I don't
believe all of them are necessary as language is a matter of personal
preference. :) I will consider your suggestions carefully and pick up
those which are really necessary.
- Leo
-Original Message-
From: WANG Cong [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 19, 2007 11:36 PM
To: Li Yang-r58472
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; TripleX Chung;
Maggie Chen;
Tejun Heo; Fengguang Wu; Chen Li-jun
Subject: Re: [PATCH] Chinese translation of Documentation/HOWTO
On Tue, Jun 19, 2007 at 10:21:03PM +0800, Li Yang wrote:
This is a Chinese translated version of Documentation/HOWTO.
Currently
Chinese involvement in Linux kernel is very low, especially comparing
to
its largest population base. Language could be the main obstacle.
Hope
this document will help more Chinese to contribute to Linux kernel.
Thanks for your work!
I hope people here who don't understand Chinese won't mind if I
comment the
following patch in Chinese. ;)
{snip}
-
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] Chinese translation of Documentation/HOWTO
-Original Message- From: dave young [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 20, 2007 9:58 AM To: WANG Cong Cc: Li Yang-r58472; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; TripleX Chung; Maggie Chen; Tejun Heo; Fengguang Wu; Chen Li-jun Subject: Re: [PATCH] Chinese translation of Documentation/HOWTO Hi, IMHO, it is not very suitable for translations merging into kernel. first, It's impossible to be 100% accurate. It can be accurate by meaning. And it can be improved. second, two or more language need to be synced with english one, it's a problem in the long run. This can be done through good maintenance. I don't think it's harder than maintaining the code in kernel source tree. - Leo - 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] Add select PHYLIB to the UCC_GETH Kconfig option
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jeff Garzik > Sent: Friday, May 25, 2007 5:48 AM > To: Jan Altenberg > Cc: Phillips Kim-R1AAHA; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] > Subject: Re: [PATCH] Add select PHYLIB to the UCC_GETH Kconfig option > > Jan Altenberg wrote: > > ucc_geth has been migrated to use the common phylib code. So lets add a > > 'select PHYLIB' to the UCC_GETH Kconfig entry. > > > > Signed-off-by: Jan Altenberg <[EMAIL PROTECTED]> > > > > --- > > drivers/net/Kconfig |1 + > > 1 file changed, 1 insertion(+) > > > > Index: linux-2.6/drivers/net/Kconfig > > === > > --- linux-2.6.orig/drivers/net/Kconfig > > +++ linux-2.6/drivers/net/Kconfig > > @@ -2280,6 +2280,7 @@ config GFAR_NAPI > > config UCC_GETH > > tristate "Freescale QE Gigabit Ethernet" > > depends on QUICC_ENGINE > > + select PHYLIB > > select UCC_FAST > > Please fix the Kconfig warnings first. > I will follow up this. > Also, I ask again: WHO IS THE MAINTAINER OF THIS DRIVER? > > I am tired of five independent people patching the same driver. Sorry for the trouble, I will post a patch to the MAINTAINER file and help to maintain ucc_geth related patches. - Leo - 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] Add select PHYLIB to the UCC_GETH Kconfig option
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik Sent: Friday, May 25, 2007 5:48 AM To: Jan Altenberg Cc: Phillips Kim-R1AAHA; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH] Add select PHYLIB to the UCC_GETH Kconfig option Jan Altenberg wrote: ucc_geth has been migrated to use the common phylib code. So lets add a 'select PHYLIB' to the UCC_GETH Kconfig entry. Signed-off-by: Jan Altenberg [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 file changed, 1 insertion(+) Index: linux-2.6/drivers/net/Kconfig === --- linux-2.6.orig/drivers/net/Kconfig +++ linux-2.6/drivers/net/Kconfig @@ -2280,6 +2280,7 @@ config GFAR_NAPI config UCC_GETH tristate Freescale QE Gigabit Ethernet depends on QUICC_ENGINE + select PHYLIB select UCC_FAST Please fix the Kconfig warnings first. I will follow up this. Also, I ask again: WHO IS THE MAINTAINER OF THIS DRIVER? I am tired of five independent people patching the same driver. Sorry for the trouble, I will post a patch to the MAINTAINER file and help to maintain ucc_geth related patches. - Leo - 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 2/2] powerpc: Fix Section mismatch warnings
> -Original Message- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 15, 2007 10:07 PM > To: Li Yang-r58472 > Cc: Paul; [EMAIL PROTECTED]; Linux Kernel > Subject: Re: [PATCH 2/2] powerpc: Fix Section mismatch warnings > > > On May 14, 2007, at 5:59 AM, Li Yang wrote: > > > This patch fix the following Section mismatch warnings > > in powerpc code. > > > > WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: > > reference to .init.data:mv643xx_eth_pd_devs from .text between > > 'mv643xx_eth_add_pds' (at offset 0x9ed2) and 'gg2_read_config' > > WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: > > reference to .init.data:mv643xx_eth_pd_devs from .text between > > 'mv643xx_eth_add_pds' (at offset 0x9ed6) and 'gg2_read_config' > > WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: > > reference to .init.text:note_scsi_host from __ksymtab between > > '__ksymtab_note_scsi_host' (at offset 0x8) and '__ksymtab_sys_ctrler' > > > > Signed-off-by: Li Yang <[EMAIL PROTECTED]> > > --- > > arch/powerpc/platforms/chrp/pegasos_eth.c |2 +- > > arch/powerpc/platforms/powermac/setup.c |2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > Did you change anything? Nothing yet. I think it's a delay of mail system. - Leo - 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 1/2] kbuild: Add "Section mismatch" warning whitelist for powerpc
> -Original Message- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > Sent: Monday, May 14, 2007 9:57 PM > To: Sam Ravnborg > Cc: Li Yang-r58472; Linus; Andrew Morton; Linux Kernel; [EMAIL PROTECTED] > Subject: Re: [PATCH 1/2] kbuild: Add "Section mismatch" warning whitelist for > powerpc > > > On May 14, 2007, at 6:06 AM, Sam Ravnborg wrote: > > > On Mon, May 14, 2007 at 06:53:32PM +0800, Li Yang wrote: > >> This patch fixes the following "Section mismatch" warnings when > >> build powerpc platforms. > >> > >> - > >> WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to > >> .init.text:early_get_page from .text between > >> 'pte_alloc_one_kernel' (at > >> offset 0xc68) and 'pte_alloc_one' > >> WARNING: mm/built-in.o - Section mismatch: reference to > >> .init.text:set_up_list3s from .text between > >> 'kmem_cache_create' (at offset > >> 0x20300) and 'cache_reap' > >> - > > This warnings should be handled by __init_refok instead. Yes. When __init_refok gets in, we can change all Pattern 9 members in the whitelist to use __init_refok. - Leo - 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 1/2] kbuild: Add "Section mismatch" warning whitelist for powerpc
> -Original Message- > From: Satyam Sharma [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 15, 2007 8:18 AM > To: Kumar Gala > Cc: Sam Ravnborg; Li Yang-r58472; Linus; Andrew Morton; Linux Kernel; > [EMAIL PROTECTED] > Subject: Re: [PATCH 1/2] kbuild: Add "Section mismatch" warning whitelist for > powerpc > > Hi, > > On 5/14/07, Kumar Gala <[EMAIL PROTECTED]> wrote: > > > > On May 14, 2007, at 6:06 AM, Sam Ravnborg wrote: > > > > > On Mon, May 14, 2007 at 06:53:32PM +0800, Li Yang wrote: > > >> This patch fixes the following "Section mismatch" warnings when > > >> build powerpc platforms. > > >> > > >> - > > >> WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to > > >> .init.text:early_get_page from .text between > > >> 'pte_alloc_one_kernel' (at > > >> offset 0xc68) and 'pte_alloc_one' > > >> WARNING: mm/built-in.o - Section mismatch: reference to > > >> .init.text:set_up_list3s from .text between > > >> 'kmem_cache_create' (at offset > > >> 0x20300) and 'cache_reap' > > >> - > > > > This warnings should be handled by __init_refok instead. > > Actually, once __init_refok comes in, would we need any other > whitelisting mechanism at all? I think the exception patterns in > secref_whitelist() and those two other whitelisting functions > (init_section_ref_ok and exit_section_ref_ok) could all be > subsumed and made redundant if / when __init_refok is used > in the actual sources. I don't think so. __init_refok can be used to mark special functions which are legitimate to reference .init.text/.init.data but cannot be used to mark special sections. - Leo - 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 1/2] kbuild: Add Section mismatch warning whitelist for powerpc
-Original Message- From: Satyam Sharma [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 8:18 AM To: Kumar Gala Cc: Sam Ravnborg; Li Yang-r58472; Linus; Andrew Morton; Linux Kernel; [EMAIL PROTECTED] Subject: Re: [PATCH 1/2] kbuild: Add Section mismatch warning whitelist for powerpc Hi, On 5/14/07, Kumar Gala [EMAIL PROTECTED] wrote: On May 14, 2007, at 6:06 AM, Sam Ravnborg wrote: On Mon, May 14, 2007 at 06:53:32PM +0800, Li Yang wrote: This patch fixes the following Section mismatch warnings when build powerpc platforms. - WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to .init.text:early_get_page from .text between 'pte_alloc_one_kernel' (at offset 0xc68) and 'pte_alloc_one' WARNING: mm/built-in.o - Section mismatch: reference to .init.text:set_up_list3s from .text between 'kmem_cache_create' (at offset 0x20300) and 'cache_reap' - This warnings should be handled by __init_refok instead. Actually, once __init_refok comes in, would we need any other whitelisting mechanism at all? I think the exception patterns in secref_whitelist() and those two other whitelisting functions (init_section_ref_ok and exit_section_ref_ok) could all be subsumed and made redundant if / when __init_refok is used in the actual sources. I don't think so. __init_refok can be used to mark special functions which are legitimate to reference .init.text/.init.data but cannot be used to mark special sections. - Leo - 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 1/2] kbuild: Add Section mismatch warning whitelist for powerpc
-Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Monday, May 14, 2007 9:57 PM To: Sam Ravnborg Cc: Li Yang-r58472; Linus; Andrew Morton; Linux Kernel; [EMAIL PROTECTED] Subject: Re: [PATCH 1/2] kbuild: Add Section mismatch warning whitelist for powerpc On May 14, 2007, at 6:06 AM, Sam Ravnborg wrote: On Mon, May 14, 2007 at 06:53:32PM +0800, Li Yang wrote: This patch fixes the following Section mismatch warnings when build powerpc platforms. - WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to .init.text:early_get_page from .text between 'pte_alloc_one_kernel' (at offset 0xc68) and 'pte_alloc_one' WARNING: mm/built-in.o - Section mismatch: reference to .init.text:set_up_list3s from .text between 'kmem_cache_create' (at offset 0x20300) and 'cache_reap' - This warnings should be handled by __init_refok instead. Yes. When __init_refok gets in, we can change all Pattern 9 members in the whitelist to use __init_refok. - Leo - 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 2/2] powerpc: Fix Section mismatch warnings
-Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 10:07 PM To: Li Yang-r58472 Cc: Paul; [EMAIL PROTECTED]; Linux Kernel Subject: Re: [PATCH 2/2] powerpc: Fix Section mismatch warnings On May 14, 2007, at 5:59 AM, Li Yang wrote: This patch fix the following Section mismatch warnings in powerpc code. WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:mv643xx_eth_pd_devs from .text between 'mv643xx_eth_add_pds' (at offset 0x9ed2) and 'gg2_read_config' WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:mv643xx_eth_pd_devs from .text between 'mv643xx_eth_add_pds' (at offset 0x9ed6) and 'gg2_read_config' WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.text:note_scsi_host from __ksymtab between '__ksymtab_note_scsi_host' (at offset 0x8) and '__ksymtab_sys_ctrler' Signed-off-by: Li Yang [EMAIL PROTECTED] --- arch/powerpc/platforms/chrp/pegasos_eth.c |2 +- arch/powerpc/platforms/powermac/setup.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Did you change anything? Nothing yet. I think it's a delay of mail system. - Leo - 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 1/1] ppc: Possible bug fix for FCC driver
Hi Cedric, For ppc embedded related patches, please also cc: [EMAIL PROTECTED] > We use a kernel 2.6.14 on PPC platform (MPC 8555). The FCC driver works To submit a kernel patch upstream, the patch should be against the latest kernel version which is 2.6.21-rc now. > well with a 100Mbps link. But it doesn't with a 10Mbps link. To solve > it, I modified the GFMR register init: removed TCI bit and set CRC32 bit > instead of. I don't know how these bits caused the 10M link issue. Do you have any reasoning? > Signed-off-by: Cedric Pontois <[EMAIL PROTECTED]> > > > - > > diff -ruN pa-original/arch/ppc/8260_io/fcc_enet.c > pa-patched/arch/ppc/8260_io/fcc_enet.c > --- pa-original/arch/ppc/8260_io/fcc_enet.c 2007-03-02 > 14:57:07.000197000 +0100 > +++ pa-patched/arch/ppc/8260_io/fcc_enet.c2007-03-02 > 14:57:08.38000 +0100 > @@ -2232,7 +2232,7 @@ > > /* Set GFMR to enable Ethernet operating mode. >*/ > - fccp->fcc_gfmr = (FCC_GFMR_TCI | FCC_GFMR_MODE_ENET); > + fccp->fcc_gfmr = (FCC_GFMR_TCRC_32 | FCC_GFMR_MODE_ENET); > > /* Set sync/delimiters. > */ > - 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 1/1] ppc: Possible bug fix for FCC driver
Hi Cedric, For ppc embedded related patches, please also cc: [EMAIL PROTECTED] We use a kernel 2.6.14 on PPC platform (MPC 8555). The FCC driver works To submit a kernel patch upstream, the patch should be against the latest kernel version which is 2.6.21-rc now. well with a 100Mbps link. But it doesn't with a 10Mbps link. To solve it, I modified the GFMR register init: removed TCI bit and set CRC32 bit instead of. I don't know how these bits caused the 10M link issue. Do you have any reasoning? Signed-off-by: Cedric Pontois [EMAIL PROTECTED] - diff -ruN pa-original/arch/ppc/8260_io/fcc_enet.c pa-patched/arch/ppc/8260_io/fcc_enet.c --- pa-original/arch/ppc/8260_io/fcc_enet.c 2007-03-02 14:57:07.000197000 +0100 +++ pa-patched/arch/ppc/8260_io/fcc_enet.c2007-03-02 14:57:08.38000 +0100 @@ -2232,7 +2232,7 @@ /* Set GFMR to enable Ethernet operating mode. */ - fccp-fcc_gfmr = (FCC_GFMR_TCI | FCC_GFMR_MODE_ENET); + fccp-fcc_gfmr = (FCC_GFMR_TCRC_32 | FCC_GFMR_MODE_ENET); /* Set sync/delimiters. */ - 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 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
> -Original Message-
> From: Ahmed S. Darwish [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 06, 2007 9:19 PM
> To: Li Yang-r58472
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
>
> [Please inform me if you are not the maintaner cause I'm not sure:)]
>
> Hi,
> A kmalloc casting cleanup patch.
>
> I wasn't able to compile the file drivers/net/ucc_geth.c cause of
> some not found headers (asm/of_platform.h, asm/qe.h, and others )
You need to use ARCH=powerpc to compile this driver. I don't know how
you could select this driver without using powerpc arch.
>
> Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 8243150..001109e 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -2864,8 +2864,8 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
> if (UCC_GETH_TX_BD_RING_ALIGNMENT > 4)
> align = UCC_GETH_TX_BD_RING_ALIGNMENT;
> ugeth->tx_bd_ring_offset[j] =
> - (u32) (kmalloc((u32) (length + align),
> - GFP_KERNEL));
> + kmalloc((u32) (length + align),
GFP_KERNEL);
> +
> if (ugeth->tx_bd_ring_offset[j] != 0)
> ugeth->p_tx_bd_ring[j] =
>
(void*)((ugeth->tx_bd_ring_offset[j] +
> @@ -2900,7 +2900,7 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
> if (UCC_GETH_RX_BD_RING_ALIGNMENT > 4)
> align = UCC_GETH_RX_BD_RING_ALIGNMENT;
> ugeth->rx_bd_ring_offset[j] =
> - (u32) (kmalloc((u32) (length + align),
GFP_KERNEL));
> + kmalloc((u32) (length + align),
GFP_KERNEL);
NACK about the 2 clean-ups above. Cast from pointer to integer is
required here.
> if (ugeth->rx_bd_ring_offset[j] != 0)
> ugeth->p_rx_bd_ring[j] =
>
(void*)((ugeth->rx_bd_ring_offset[j] +
> @@ -2926,10 +2926,9 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
> /* Init Tx bds */
> for (j = 0; j < ug_info->numQueuesTx; j++) {
> /* Setup the skbuff rings */
> - ugeth->tx_skbuff[j] =
> - (struct sk_buff **)kmalloc(sizeof(struct sk_buff *)
*
> -
ugeth->ug_info->bdRingLenTx[j],
> -GFP_KERNEL);
> + ugeth->tx_skbuff[j] = kmalloc(sizeof(struct sk_buff *) *
> +
ugeth->ug_info->bdRingLenTx[j],
> + GFP_KERNEL);
>
> if (ugeth->tx_skbuff[j] == NULL) {
> ugeth_err("%s: Could not allocate tx_skbuff",
> @@ -2958,10 +2957,9 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
> /* Init Rx bds */
> for (j = 0; j < ug_info->numQueuesRx; j++) {
> /* Setup the skbuff rings */
> - ugeth->rx_skbuff[j] =
> - (struct sk_buff **)kmalloc(sizeof(struct sk_buff *)
*
> -
ugeth->ug_info->bdRingLenRx[j],
> -GFP_KERNEL);
> + ugeth->rx_skbuff[j] = kmalloc(sizeof(struct sk_buff *) *
> +
ugeth->ug_info->bdRingLenRx[j],
> + GFP_KERNEL);
>
> if (ugeth->rx_skbuff[j] == NULL) {
> ugeth_err("%s: Could not allocate rx_skbuff",
> @@ -3452,8 +3450,7 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
>* allocated resources can be released when the channel is
freed.
>*/
> if (!(ugeth->p_init_enet_param_shadow =
> - (struct ucc_geth_init_pram *) kmalloc(sizeof(struct
> ucc_geth_init_pram),
> - GFP_KERNEL))) {
> + kmalloc(sizeof(struct ucc_geth_init_pram), GFP_KERNEL))) {
> ugeth_err
> ("%s: Can not allocate memory for"
> " p_UccInitEnetParamShadows.", __FUNCTION__);
>
> --
> Ahmed S. Darwish
> http://darwish-07.blogspot.com
- Leo
-
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 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
-Original Message-
From: Ahmed S. Darwish [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 06, 2007 9:19 PM
To: Li Yang-r58472
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
[Please inform me if you are not the maintaner cause I'm not sure:)]
Hi,
A kmalloc casting cleanup patch.
I wasn't able to compile the file drivers/net/ucc_geth.c cause of
some not found headers (asm/of_platform.h, asm/qe.h, and others )
You need to use ARCH=powerpc to compile this driver. I don't know how
you could select this driver without using powerpc arch.
Signed-off-by: Ahmed Darwish [EMAIL PROTECTED]
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 8243150..001109e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2864,8 +2864,8 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
if (UCC_GETH_TX_BD_RING_ALIGNMENT 4)
align = UCC_GETH_TX_BD_RING_ALIGNMENT;
ugeth-tx_bd_ring_offset[j] =
- (u32) (kmalloc((u32) (length + align),
- GFP_KERNEL));
+ kmalloc((u32) (length + align),
GFP_KERNEL);
+
if (ugeth-tx_bd_ring_offset[j] != 0)
ugeth-p_tx_bd_ring[j] =
(void*)((ugeth-tx_bd_ring_offset[j] +
@@ -2900,7 +2900,7 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
if (UCC_GETH_RX_BD_RING_ALIGNMENT 4)
align = UCC_GETH_RX_BD_RING_ALIGNMENT;
ugeth-rx_bd_ring_offset[j] =
- (u32) (kmalloc((u32) (length + align),
GFP_KERNEL));
+ kmalloc((u32) (length + align),
GFP_KERNEL);
NACK about the 2 clean-ups above. Cast from pointer to integer is
required here.
if (ugeth-rx_bd_ring_offset[j] != 0)
ugeth-p_rx_bd_ring[j] =
(void*)((ugeth-rx_bd_ring_offset[j] +
@@ -2926,10 +2926,9 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
/* Init Tx bds */
for (j = 0; j ug_info-numQueuesTx; j++) {
/* Setup the skbuff rings */
- ugeth-tx_skbuff[j] =
- (struct sk_buff **)kmalloc(sizeof(struct sk_buff *)
*
-
ugeth-ug_info-bdRingLenTx[j],
-GFP_KERNEL);
+ ugeth-tx_skbuff[j] = kmalloc(sizeof(struct sk_buff *) *
+
ugeth-ug_info-bdRingLenTx[j],
+ GFP_KERNEL);
if (ugeth-tx_skbuff[j] == NULL) {
ugeth_err(%s: Could not allocate tx_skbuff,
@@ -2958,10 +2957,9 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
/* Init Rx bds */
for (j = 0; j ug_info-numQueuesRx; j++) {
/* Setup the skbuff rings */
- ugeth-rx_skbuff[j] =
- (struct sk_buff **)kmalloc(sizeof(struct sk_buff *)
*
-
ugeth-ug_info-bdRingLenRx[j],
-GFP_KERNEL);
+ ugeth-rx_skbuff[j] = kmalloc(sizeof(struct sk_buff *) *
+
ugeth-ug_info-bdRingLenRx[j],
+ GFP_KERNEL);
if (ugeth-rx_skbuff[j] == NULL) {
ugeth_err(%s: Could not allocate rx_skbuff,
@@ -3452,8 +3450,7 @@ static int ucc_geth_startup(struct
ucc_geth_private *ugeth)
* allocated resources can be released when the channel is
freed.
*/
if (!(ugeth-p_init_enet_param_shadow =
- (struct ucc_geth_init_pram *) kmalloc(sizeof(struct
ucc_geth_init_pram),
- GFP_KERNEL))) {
+ kmalloc(sizeof(struct ucc_geth_init_pram), GFP_KERNEL))) {
ugeth_err
(%s: Can not allocate memory for
p_UccInitEnetParamShadows., __FUNCTION__);
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
- Leo
-
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 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
> -Original Message- > From: Ahmed S. Darwish [mailto:[EMAIL PROTECTED] > Sent: Monday, January 08, 2007 12:27 PM > To: Li Yang-r58472 > Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org > Subject: Re: [PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups > > On Mon, Jan 08, 2007 at 11:12:28AM +0800, Li Yang-r58472 wrote: > > > From: Ahmed S. Darwish [mailto:[EMAIL PROTECTED] > > > > > > Hi, > > > A kmalloc casting cleanup patch. > > > Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]> > > [..] > > > > - (u32) (kmalloc((u32) (length + align), > > > - GFP_KERNEL)); > > > + kmalloc((u32) (length + align), GFP_KERNEL); > > > + > > > if (ugeth->tx_bd_ring_offset[j] != 0) > > > ugeth->p_tx_bd_ring[j] = > > [..] > > > > - (u32) (kmalloc((u32) (length + align), GFP_KERNEL)); > > > + kmalloc((u32) (length + align), GFP_KERNEL); > > > > NACK about the 2 clean-ups above. Cast from pointer to integer is > > required here. > > Are the casts from pointer to integer just needed to suppress gcc > warnings or there's something technically important about them ? It is to suppress the warnings. IMHO, most type casts are not technically important but for sanity check. - Leo - 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 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
-Original Message- From: Ahmed S. Darwish [mailto:[EMAIL PROTECTED] Sent: Monday, January 08, 2007 12:27 PM To: Li Yang-r58472 Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org Subject: Re: [PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups On Mon, Jan 08, 2007 at 11:12:28AM +0800, Li Yang-r58472 wrote: From: Ahmed S. Darwish [mailto:[EMAIL PROTECTED] Hi, A kmalloc casting cleanup patch. Signed-off-by: Ahmed Darwish [EMAIL PROTECTED] [..] - (u32) (kmalloc((u32) (length + align), - GFP_KERNEL)); + kmalloc((u32) (length + align), GFP_KERNEL); + if (ugeth-tx_bd_ring_offset[j] != 0) ugeth-p_tx_bd_ring[j] = [..] - (u32) (kmalloc((u32) (length + align), GFP_KERNEL)); + kmalloc((u32) (length + align), GFP_KERNEL); NACK about the 2 clean-ups above. Cast from pointer to integer is required here. Are the casts from pointer to integer just needed to suppress gcc warnings or there's something technically important about them ? It is to suppress the warnings. IMHO, most type casts are not technically important but for sanity check. - Leo - 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/
Can't update from Linus' tree
Hi all, I can't update from Linus' tree today. Is anyone else having the same problem as I did? Recovering from a previously interrupted fetch... Fetching head... Fetching objects... Getting alternates list for http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ error: Unable to find e25db641c0e6dd49c5db24dbe154048d4a466727 under http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ Cannot obtain needed none e25db641c0e6dd49c5db24dbe154048d4a466727 while processing commit . progress: 0 objects, 0 bytes cg-fetch: objects fetch failed - Leo - 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/
Can't update from Linus' tree
Hi all, I can't update from Linus' tree today. Is anyone else having the same problem as I did? Recovering from a previously interrupted fetch... Fetching head... Fetching objects... Getting alternates list for http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ error: Unable to find e25db641c0e6dd49c5db24dbe154048d4a466727 under http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ Cannot obtain needed none e25db641c0e6dd49c5db24dbe154048d4a466727 while processing commit . progress: 0 objects, 0 bytes cg-fetch: objects fetch failed - Leo - 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/
