Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Fri, Dec 20, 2013 at 09:23:46PM +0100, Arnaud Ebalard wrote: > I do not even know to which specific component the irq line of the chip > is connected. You can take a look at [1] to see what's on the PCB; if > you have an idea about which one could be a good candidate (TPS65251?), > I can try and check with an ohmmeter which pin is connected to confirm > your guess. Then, I could look at the datasheet (if any) to see if it > can relay the interrupt to the SoC (if the component is supported by > Linux kernel). That's a PMIC which is what I'd expect if it's able to wake the device - if it's anything like the other TI PMICs it ought to be able to act as an interrupt controller. -- 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: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Fri, Dec 20, 2013 at 09:23:46PM +0100, Arnaud Ebalard wrote: I do not even know to which specific component the irq line of the chip is connected. You can take a look at [1] to see what's on the PCB; if you have an idea about which one could be a good candidate (TPS65251?), I can try and check with an ohmmeter which pin is connected to confirm your guess. Then, I could look at the datasheet (if any) to see if it can relay the interrupt to the SoC (if the component is supported by Linux kernel). That's a PMIC which is what I'd expect if it's able to wake the device - if it's anything like the other TI PMICs it ought to be able to act as an interrupt controller. -- 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: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
Hi, Mark Brown writes: > On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote: > >> All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which >> is used as main RTC clock but can also provide alarm. But the alarm >> interrupt line of the chip is *not* connected to the SoC. It is >> connected to some power component and can be used to wake up the NAS >> when it is completely off and the alarm rings. > > Can the PMIC or whatever function as an interrupt controller and report > the interrupt on to the SoC? I do not even know to which specific component the irq line of the chip is connected. You can take a look at [1] to see what's on the PCB; if you have an idea about which one could be a good candidate (TPS65251?), I can try and check with an ohmmeter which pin is connected to confirm your guess. Then, I could look at the datasheet (if any) to see if it can relay the interrupt to the SoC (if the component is supported by Linux kernel). But, except if we can do what you propose, there are two problems at hand: 1) I cannot currently test the IRQ handler my changes would bring because it is not connected to the SoC on my platforms 2) even if I find a solution for 1), noone ever provided any directions on what should be required to make some program like rtc-test.c happy on my platforms (alarm support but no interrupt from the RTC). e.g. some refinements like the one introduced by c9f5c7e7a84f1b7 (rtc: rtc-spear: Provide flag for no support of UIE mode). I guess it should be fairly simple for someone w/ good knowledge of the RTC subsystem to tell what is needed. I do not have that knowledge and the documentation does not help. Regarding 1), I am starting to wonder if the best way out would not be for me to connect the interrupt line of the ISL12057 to one of the GPIO line currently connected to the LCD on my RN104 (after having disconnected the LCD) and change the function of the associated MPP on the SoC to make it an interrupt line. Could that work w/o additional hardware modification? What are my chances of killing the board? But this is pointless if I do not get any clear directions about 2). Cheers, a+ [1]: http://natisbad.org/NAS2/index.html#hw -- 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: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote: > All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which > is used as main RTC clock but can also provide alarm. But the alarm > interrupt line of the chip is *not* connected to the SoC. It is > connected to some power component and can be used to wake up the NAS > when it is completely off and the alarm rings. Can the PMIC or whatever function as an interrupt controller and report the interrupt on to the SoC? signature.asc Description: Digital signature
Re: Can someone Ack and queue a patch for RTC subsytem?
Hi Alessandro, On Thu, Dec 19, 2013 at 06:49:24PM +0100, Alessandro Zummo wrote: > On Thu, 19 Dec 2013 18:46:18 +0100 > a...@natisbad.org (Arnaud Ebalard) wrote: > > > > I don't mind routing it though mvebu/arm-soc since the only consumers > > > are currently mvebu boards, but I'd like to hear from Andrew that this > > > is ok. > > > > I will do what you think is the best. > > If the only consumers are mvebu boards, I believe it is correct to > route though that tree. imho. We're pretty much in the same situation for the Allwinner RTC driver http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211849.html I'm fine with merging it through my tree, however, we still need some reviews and an Acked-by from you. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: Can someone Ack and queue a patch for RTC subsytem?
Hi Alessandro, On Thu, Dec 19, 2013 at 06:49:24PM +0100, Alessandro Zummo wrote: On Thu, 19 Dec 2013 18:46:18 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: I don't mind routing it though mvebu/arm-soc since the only consumers are currently mvebu boards, but I'd like to hear from Andrew that this is ok. I will do what you think is the best. If the only consumers are mvebu boards, I believe it is correct to route though that tree. imho. We're pretty much in the same situation for the Allwinner RTC driver http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211849.html I'm fine with merging it through my tree, however, we still need some reviews and an Acked-by from you. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote: All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which is used as main RTC clock but can also provide alarm. But the alarm interrupt line of the chip is *not* connected to the SoC. It is connected to some power component and can be used to wake up the NAS when it is completely off and the alarm rings. Can the PMIC or whatever function as an interrupt controller and report the interrupt on to the SoC? signature.asc Description: Digital signature
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
Hi, Mark Brown broo...@kernel.org writes: On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote: All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which is used as main RTC clock but can also provide alarm. But the alarm interrupt line of the chip is *not* connected to the SoC. It is connected to some power component and can be used to wake up the NAS when it is completely off and the alarm rings. Can the PMIC or whatever function as an interrupt controller and report the interrupt on to the SoC? I do not even know to which specific component the irq line of the chip is connected. You can take a look at [1] to see what's on the PCB; if you have an idea about which one could be a good candidate (TPS65251?), I can try and check with an ohmmeter which pin is connected to confirm your guess. Then, I could look at the datasheet (if any) to see if it can relay the interrupt to the SoC (if the component is supported by Linux kernel). But, except if we can do what you propose, there are two problems at hand: 1) I cannot currently test the IRQ handler my changes would bring because it is not connected to the SoC on my platforms 2) even if I find a solution for 1), noone ever provided any directions on what should be required to make some program like rtc-test.c happy on my platforms (alarm support but no interrupt from the RTC). e.g. some refinements like the one introduced by c9f5c7e7a84f1b7 (rtc: rtc-spear: Provide flag for no support of UIE mode). I guess it should be fairly simple for someone w/ good knowledge of the RTC subsystem to tell what is needed. I do not have that knowledge and the documentation does not help. Regarding 1), I am starting to wonder if the best way out would not be for me to connect the interrupt line of the ISL12057 to one of the GPIO line currently connected to the LCD on my RN104 (after having disconnected the LCD) and change the function of the associated MPP on the SoC to make it an interrupt line. Could that work w/o additional hardware modification? What are my chances of killing the board? But this is pointless if I do not get any clear directions about 2). Cheers, a+ [1]: http://natisbad.org/NAS2/index.html#hw -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 06:46:18PM +0100, Arnaud Ebalard wrote: > Hi, > > Jason Cooper writes: > > > On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote: > >> I have a very simple driver (support for reading and setting the time) > >> for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it > >> Acked and queued for v3.14. In v3.14, there should be at least three > >> users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff > >> for associated .dts changes. > > > > The -rc5 cutoff isn't a hard line. It's also mvebu-specific. eg, We > > need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we > > have time to get the pull request in. If it needs to go through > > mvebu/arm-soc, once it's posted, you're good. > > I understand. But I guess you will not (for valid reason) accept .dts > changes to reference a rtc driver that is not on good track towards > -next. This is the issue I try and solve. Just a subtle note here. If the binding is stabilized, I don't mind taking the dts changes. However, if we have time, I prefer to wait for the whole series to be hashed out. You never know which resolutions will end up revisiting the bindings you thought were good. :) So, it's technically not a requirement for the whole driver to be settled, but it is a good idea. thx, Jason. -- 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: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
Hi, Alessandro Zummo writes: > On Thu, 19 Dec 2013 11:46:24 -0500 > Jason Cooper wrote: > >> In the long term, should we seek out a co-maintainer for drivers/rtc? >> Can anyone get a hold of Alessandro to get his opinion on this? > > I'd surely appreciate if someone can take some time to give > a look to the patches. Most of them go thru subsystem's tree and, as > far as I can see, I saw very relevant comments and fixes in all those > years. While I am at it, I wonder if you can give me some directions on the following to add back alarm support to the ISL12057 on the specific hardware I have. All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which is used as main RTC clock but can also provide alarm. But the alarm interrupt line of the chip is *not* connected to the SoC. It is connected to some power component and can be used to wake up the NAS when it is completely off and the alarm rings. To me this kind of setup seems logical but it does not seem to be directly supported by current RTC logic: - first, I cannot test an interrupt handler implementation I had written as the SoC will never receive any interrupt. This limits my ability to provide one to the driver. - what can/should be done in my .dts file to indicate that the device does not have any IRQ line connected (and hence no interrupt handler) to the SoC but still supports an alarm. As a side note, the implementation I had was a working one on my hardware (i.e. was able to wake up the device at a given time) but I had to remove alarm code to get a basic driver accepted upstream. To be honest, I tried and understand what RTC subsystem expects from documentation and code w/o success. Any help appreciated on that topic. Cheers, a+ -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 11:48:37AM -0800, Guenter Roeck wrote: > On Thu, Dec 19, 2013 at 01:09:40PM -0500, Jason Cooper wrote: > > On Thu, Dec 19, 2013 at 07:05:49PM +0100, Arnaud Ebalard wrote: > > > Hi, > > > > > > Alessandro Zummo writes: > > > > > > >> Do you want me to send a v7 w/ the .proc helper removed or leave > > > >> things as they are and Ack the patch as is? > > > > > > > > Unless absolutely needed, I'd prefer if you can remove them > > > > or move to sysfs. > > > > > > Well, my helper provides info on control and status registers flags > > > (just like rtc-isl1208.c does), which are useful mainly for debug I > > > guess. If this can help pushing things forward, I will send a v7 later > > > today w/ the .proc helper removed from the patch. > > > > Why not convert to debugfs? > > > Separate follow-on patch, maybe, to keep things going ? Sure. thx, Jason. -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 01:09:40PM -0500, Jason Cooper wrote: > On Thu, Dec 19, 2013 at 07:05:49PM +0100, Arnaud Ebalard wrote: > > Hi, > > > > Alessandro Zummo writes: > > > > >> Do you want me to send a v7 w/ the .proc helper removed or leave > > >> things as they are and Ack the patch as is? > > > > > > Unless absolutely needed, I'd prefer if you can remove them > > > or move to sysfs. > > > > Well, my helper provides info on control and status registers flags > > (just like rtc-isl1208.c does), which are useful mainly for debug I > > guess. If this can help pushing things forward, I will send a v7 later > > today w/ the .proc helper removed from the patch. > > Why not convert to debugfs? > Separate follow-on patch, maybe, to keep things going ? Guenter -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 07:05:49PM +0100, Arnaud Ebalard wrote: > Hi, > > Alessandro Zummo writes: > > >> Do you want me to send a v7 w/ the .proc helper removed or leave > >> things as they are and Ack the patch as is? > > > > Unless absolutely needed, I'd prefer if you can remove them > > or move to sysfs. > > Well, my helper provides info on control and status registers flags > (just like rtc-isl1208.c does), which are useful mainly for debug I > guess. If this can help pushing things forward, I will send a v7 later > today w/ the .proc helper removed from the patch. Why not convert to debugfs? thx, Jason. -- 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: Can someone Ack and queue a patch for RTC subsytem?
Hi, Alessandro Zummo writes: >> Do you want me to send a v7 w/ the .proc helper removed or leave >> things as they are and Ack the patch as is? > > Unless absolutely needed, I'd prefer if you can remove them > or move to sysfs. Well, my helper provides info on control and status registers flags (just like rtc-isl1208.c does), which are useful mainly for debug I guess. If this can help pushing things forward, I will send a v7 later today w/ the .proc helper removed from the patch. Cheers, a+ -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 13:01:36 -0500 Jason Cooper wrote: > That goes against the whole goal of the arm-soc devicetree conversion. > For the past several years, we've been moving drivers _out_ of arch/arm/ > into the appropriate drivers/ area. The goal of this was to unclutter > arch/arm/, and to more readily see and remove code duplication by > drivers. I meant in drivers/rtc but using another tree. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 06:40:24PM +0100, Alessandro Zummo wrote: > On Thu, 19 Dec 2013 18:28:16 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: > > At some point, Alessandro Zummo wrote: ... > > > I do not maintain a separate tree due to most RTCs being specifit to a > > > subsytem. > > > > I do not understand: the chip is generic, i.e. this is not a RTC chip > > specific to a given SoC (like rtc-mv.c is for instance). Can you be > > more specific? > > Yes, this chip is generic, but most aren't. Some of those who > are generic, are strictly connected to a particular system/board, > and they end up in that system's tree. Most of the drivers > are pretty small. That goes against the whole goal of the arm-soc devicetree conversion. For the past several years, we've been moving drivers _out_ of arch/arm/ into the appropriate drivers/ area. The goal of this was to unclutter arch/arm/, and to more readily see and remove code duplication by drivers. thx, Jason. -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 06:46:18PM +0100, Arnaud Ebalard wrote: > Jason Cooper writes: > > On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote: ... > >> I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to > >> take care of the v6 I just sent [1]. > > > > I don't mind routing it though mvebu/arm-soc since the only consumers > > are currently mvebu boards, but I'd like to hear from Andrew that this > > is ok. > > I will do what you think is the best. It sounds like once you address Alessandro's concerns about /proc entries, we should be able to take v7 through mvebu/arm-soc. thx, Jason. -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 18:46:18 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: > > I don't mind routing it though mvebu/arm-soc since the only consumers > > are currently mvebu boards, but I'd like to hear from Andrew that this > > is ok. > > I will do what you think is the best. If the only consumers are mvebu boards, I believe it is correct to route though that tree. imho. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
Hi, Jason Cooper writes: > On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote: >> I have a very simple driver (support for reading and setting the time) >> for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it >> Acked and queued for v3.14. In v3.14, there should be at least three >> users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff >> for associated .dts changes. > > The -rc5 cutoff isn't a hard line. It's also mvebu-specific. eg, We > need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we > have time to get the pull request in. If it needs to go through > mvebu/arm-soc, once it's posted, you're good. I understand. But I guess you will not (for valid reason) accept .dts changes to reference a rtc driver that is not on good track towards -next. This is the issue I try and solve. >> I never heard of *listed* RTC maintainer during all the review process >> on rtc-linux list (v0 sent in october); I dug the list archives and when >> this previously happened, someone else (e.g. Andrew Morton) was kind >> enough to handle the patches: >> >> http://www.spinics.net/lists/arm-kernel/msg292187.html > > Unfortunately, it doesn't look like Alessandro has been active for a > while and Andrew Morton has indeed been picking up the slack. S-o-B's > confirm this. > > I haven't worked with Andrew enough to know his workflow, but I imagine > he can take patches much closer to the merge window than we can. > >> I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to >> take care of the v6 I just sent [1]. > > I don't mind routing it though mvebu/arm-soc since the only consumers > are currently mvebu boards, but I'd like to hear from Andrew that this > is ok. I will do what you think is the best. Cheers, a+ -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 18:28:16 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: > > Yes, Andrew usually pick those. > > I guess he should be put in the MAINTAINERS file then. Otherwise, > get_maintainer.pl script can not do its job correctly and people > end up thinking you should be the one handling those. That makes sense, I'll leave the decision add his email to Andrew. > > I do not maintain a separate tree due to most RTCs being specifit to a > > subsytem. > > I do not understand: the chip is generic, i.e. this is not a RTC chip > specific to a given SoC (like rtc-mv.c is for instance). Can you be > more specific? Yes, this chip is generic, but most aren't. Some of those who are generic, are strictly connected to a particular system/board, and they end up in that system's tree. Most of the drivers are pretty small. > > Regarding your patch, please do not add entries to /proc. > > Use sysfs if you need. > > Well, this is what is currently described in the documentation > (Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what > many drivers do (AFAICT, 22/125). This needs to be fixed as well. Documentation.txt does not suggest to add arbitrary values to the procfs. "many do" does not apply. > Additionally, I only provide some additional info for an existing > file: the /proc entry is created by the drivers/rtc/class.c as > soon as someone selects CONFIG_RTC_INTF_PROC. I know, but that makes the procfs entry a mess. sysfs is the way, > Do you want me to send a v7 w/ the .proc helper removed or leave > things as they are and Ack the patch as is? Unless absolutely needed, I'd prefer if you can remove them or move to sysfs. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
Hi, Alessandro Zummo writes: > On Thu, 19 Dec 2013 17:34:09 +0100 > a...@natisbad.org (Arnaud Ebalard) wrote: > >> I never heard of *listed* RTC maintainer during all the review process >> on rtc-linux list (v0 sent in october); I dug the list archives and when >> this previously happened, someone else (e.g. Andrew Morton) was kind >> enough to handle the patches: > > Yes, Andrew usually pick those. I guess he should be put in the MAINTAINERS file then. Otherwise, get_maintainer.pl script can not do its job correctly and people end up thinking you should be the one handling those. > I do not maintain a separate tree due to most RTCs being specifit to a > subsytem. I do not understand: the chip is generic, i.e. this is not a RTC chip specific to a given SoC (like rtc-mv.c is for instance). Can you be more specific? >> http://www.spinics.net/lists/arm-kernel/msg292187.html > > Regarding your patch, please do not add entries to /proc. > Use sysfs if you need. Well, this is what is currently described in the documentation (Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what many drivers do (AFAICT, 22/125). Additionally, I only provide some additional info for an existing file: the /proc entry is created by the drivers/rtc/class.c as soon as someone selects CONFIG_RTC_INTF_PROC. Do you want me to send a v7 w/ the .proc helper removed or leave things as they are and Ack the patch as is? Cheers, a+ -- 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: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 11:46:24 -0500 Jason Cooper wrote: > In the long term, should we seek out a co-maintainer for drivers/rtc? > Can anyone get a hold of Alessandro to get his opinion on this? I'd surely appreciate if someone can take some time to give a look to the patches. Most of them go thru subsystem's tree and, as far as I can see, I saw very relevant comments and fixes in all those years. I'd love to devote more time to Linux but I'd need to find someone that hires me just to do that the whole day :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
Arnaud, On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote: > I have a very simple driver (support for reading and setting the time) > for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it > Acked and queued for v3.14. In v3.14, there should be at least three > users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff > for associated .dts changes. The -rc5 cutoff isn't a hard line. It's also mvebu-specific. eg, We need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we have time to get the pull request in. If it needs to go through mvebu/arm-soc, once it's posted, you're good. The rtc driver shouldn't go through mvebu/arm-soc. It should go through the rtc maintainer's tree. > I never heard of *listed* RTC maintainer during all the review process > on rtc-linux list (v0 sent in october); I dug the list archives and when > this previously happened, someone else (e.g. Andrew Morton) was kind > enough to handle the patches: > > http://www.spinics.net/lists/arm-kernel/msg292187.html Unfortunately, it doesn't look like Alessandro has been active for a while and Andrew Morton has indeed been picking up the slack. S-o-B's confirm this. I haven't worked with Andrew enough to know his workflow, but I imagine he can take patches much closer to the merge window than we can. > I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to > take care of the v6 I just sent [1]. I don't mind routing it though mvebu/arm-soc since the only consumers are currently mvebu boards, but I'd like to hear from Andrew that this is ok. In the long term, should we seek out a co-maintainer for drivers/rtc? Can anyone get a hold of Alessandro to get his opinion on this? thx, Jason. > [1]: http://patchwork.ozlabs.org/patch/303616/ -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 17:34:09 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: > I never heard of *listed* RTC maintainer during all the review process > on rtc-linux list (v0 sent in october); I dug the list archives and when > this previously happened, someone else (e.g. Andrew Morton) was kind > enough to handle the patches: Yes, Andrew usually pick those. I do not maintain a separate tree due to most RTCs being specifit to a subsytem. > > http://www.spinics.net/lists/arm-kernel/msg292187.html Regarding your patch, please do not add entries to /proc. Use sysfs if you need. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 17:34:09 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: I never heard of *listed* RTC maintainer during all the review process on rtc-linux list (v0 sent in october); I dug the list archives and when this previously happened, someone else (e.g. Andrew Morton) was kind enough to handle the patches: Yes, Andrew usually pick those. I do not maintain a separate tree due to most RTCs being specifit to a subsytem. http://www.spinics.net/lists/arm-kernel/msg292187.html Regarding your patch, please do not add entries to /proc. Use sysfs if you need. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
Arnaud, On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote: I have a very simple driver (support for reading and setting the time) for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it Acked and queued for v3.14. In v3.14, there should be at least three users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff for associated .dts changes. The -rc5 cutoff isn't a hard line. It's also mvebu-specific. eg, We need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we have time to get the pull request in. If it needs to go through mvebu/arm-soc, once it's posted, you're good. The rtc driver shouldn't go through mvebu/arm-soc. It should go through the rtc maintainer's tree. I never heard of *listed* RTC maintainer during all the review process on rtc-linux list (v0 sent in october); I dug the list archives and when this previously happened, someone else (e.g. Andrew Morton) was kind enough to handle the patches: http://www.spinics.net/lists/arm-kernel/msg292187.html Unfortunately, it doesn't look like Alessandro has been active for a while and Andrew Morton has indeed been picking up the slack. S-o-B's confirm this. I haven't worked with Andrew enough to know his workflow, but I imagine he can take patches much closer to the merge window than we can. I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to take care of the v6 I just sent [1]. I don't mind routing it though mvebu/arm-soc since the only consumers are currently mvebu boards, but I'd like to hear from Andrew that this is ok. In the long term, should we seek out a co-maintainer for drivers/rtc? Can anyone get a hold of Alessandro to get his opinion on this? thx, Jason. [1]: http://patchwork.ozlabs.org/patch/303616/ -- 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: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 11:46:24 -0500 Jason Cooper ja...@lakedaemon.net wrote: In the long term, should we seek out a co-maintainer for drivers/rtc? Can anyone get a hold of Alessandro to get his opinion on this? I'd surely appreciate if someone can take some time to give a look to the patches. Most of them go thru subsystem's tree and, as far as I can see, I saw very relevant comments and fixes in all those years. I'd love to devote more time to Linux but I'd need to find someone that hires me just to do that the whole day :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
Hi, Alessandro Zummo a.zu...@towertech.it writes: On Thu, 19 Dec 2013 17:34:09 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: I never heard of *listed* RTC maintainer during all the review process on rtc-linux list (v0 sent in october); I dug the list archives and when this previously happened, someone else (e.g. Andrew Morton) was kind enough to handle the patches: Yes, Andrew usually pick those. I guess he should be put in the MAINTAINERS file then. Otherwise, get_maintainer.pl script can not do its job correctly and people end up thinking you should be the one handling those. I do not maintain a separate tree due to most RTCs being specifit to a subsytem. I do not understand: the chip is generic, i.e. this is not a RTC chip specific to a given SoC (like rtc-mv.c is for instance). Can you be more specific? http://www.spinics.net/lists/arm-kernel/msg292187.html Regarding your patch, please do not add entries to /proc. Use sysfs if you need. Well, this is what is currently described in the documentation (Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what many drivers do (AFAICT, 22/125). Additionally, I only provide some additional info for an existing file: the /proc entry is created by the drivers/rtc/class.c as soon as someone selects CONFIG_RTC_INTF_PROC. Do you want me to send a v7 w/ the .proc helper removed or leave things as they are and Ack the patch as is? Cheers, a+ -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 18:28:16 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: Yes, Andrew usually pick those. I guess he should be put in the MAINTAINERS file then. Otherwise, get_maintainer.pl script can not do its job correctly and people end up thinking you should be the one handling those. That makes sense, I'll leave the decision add his email to Andrew. I do not maintain a separate tree due to most RTCs being specifit to a subsytem. I do not understand: the chip is generic, i.e. this is not a RTC chip specific to a given SoC (like rtc-mv.c is for instance). Can you be more specific? Yes, this chip is generic, but most aren't. Some of those who are generic, are strictly connected to a particular system/board, and they end up in that system's tree. Most of the drivers are pretty small. Regarding your patch, please do not add entries to /proc. Use sysfs if you need. Well, this is what is currently described in the documentation (Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what many drivers do (AFAICT, 22/125). This needs to be fixed as well. Documentation.txt does not suggest to add arbitrary values to the procfs. many do does not apply. Additionally, I only provide some additional info for an existing file: the /proc entry is created by the drivers/rtc/class.c as soon as someone selects CONFIG_RTC_INTF_PROC. I know, but that makes the procfs entry a mess. sysfs is the way, Do you want me to send a v7 w/ the .proc helper removed or leave things as they are and Ack the patch as is? Unless absolutely needed, I'd prefer if you can remove them or move to sysfs. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
Hi, Jason Cooper ja...@lakedaemon.net writes: On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote: I have a very simple driver (support for reading and setting the time) for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it Acked and queued for v3.14. In v3.14, there should be at least three users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff for associated .dts changes. The -rc5 cutoff isn't a hard line. It's also mvebu-specific. eg, We need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we have time to get the pull request in. If it needs to go through mvebu/arm-soc, once it's posted, you're good. I understand. But I guess you will not (for valid reason) accept .dts changes to reference a rtc driver that is not on good track towards -next. This is the issue I try and solve. I never heard of *listed* RTC maintainer during all the review process on rtc-linux list (v0 sent in october); I dug the list archives and when this previously happened, someone else (e.g. Andrew Morton) was kind enough to handle the patches: http://www.spinics.net/lists/arm-kernel/msg292187.html Unfortunately, it doesn't look like Alessandro has been active for a while and Andrew Morton has indeed been picking up the slack. S-o-B's confirm this. I haven't worked with Andrew enough to know his workflow, but I imagine he can take patches much closer to the merge window than we can. I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to take care of the v6 I just sent [1]. I don't mind routing it though mvebu/arm-soc since the only consumers are currently mvebu boards, but I'd like to hear from Andrew that this is ok. I will do what you think is the best. Cheers, a+ -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 18:46:18 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: I don't mind routing it though mvebu/arm-soc since the only consumers are currently mvebu boards, but I'd like to hear from Andrew that this is ok. I will do what you think is the best. If the only consumers are mvebu boards, I believe it is correct to route though that tree. imho. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 06:46:18PM +0100, Arnaud Ebalard wrote: Jason Cooper ja...@lakedaemon.net writes: On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote: ... I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to take care of the v6 I just sent [1]. I don't mind routing it though mvebu/arm-soc since the only consumers are currently mvebu boards, but I'd like to hear from Andrew that this is ok. I will do what you think is the best. It sounds like once you address Alessandro's concerns about /proc entries, we should be able to take v7 through mvebu/arm-soc. thx, Jason. -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 06:40:24PM +0100, Alessandro Zummo wrote: On Thu, 19 Dec 2013 18:28:16 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: At some point, Alessandro Zummo wrote: ... I do not maintain a separate tree due to most RTCs being specifit to a subsytem. I do not understand: the chip is generic, i.e. this is not a RTC chip specific to a given SoC (like rtc-mv.c is for instance). Can you be more specific? Yes, this chip is generic, but most aren't. Some of those who are generic, are strictly connected to a particular system/board, and they end up in that system's tree. Most of the drivers are pretty small. That goes against the whole goal of the arm-soc devicetree conversion. For the past several years, we've been moving drivers _out_ of arch/arm/ into the appropriate drivers/ area. The goal of this was to unclutter arch/arm/, and to more readily see and remove code duplication by drivers. thx, Jason. -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 13:01:36 -0500 Jason Cooper ja...@lakedaemon.net wrote: That goes against the whole goal of the arm-soc devicetree conversion. For the past several years, we've been moving drivers _out_ of arch/arm/ into the appropriate drivers/ area. The goal of this was to unclutter arch/arm/, and to more readily see and remove code duplication by drivers. I meant in drivers/rtc but using another tree. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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: Can someone Ack and queue a patch for RTC subsytem?
Hi, Alessandro Zummo a.zu...@towertech.it writes: Do you want me to send a v7 w/ the .proc helper removed or leave things as they are and Ack the patch as is? Unless absolutely needed, I'd prefer if you can remove them or move to sysfs. Well, my helper provides info on control and status registers flags (just like rtc-isl1208.c does), which are useful mainly for debug I guess. If this can help pushing things forward, I will send a v7 later today w/ the .proc helper removed from the patch. Cheers, a+ -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 07:05:49PM +0100, Arnaud Ebalard wrote: Hi, Alessandro Zummo a.zu...@towertech.it writes: Do you want me to send a v7 w/ the .proc helper removed or leave things as they are and Ack the patch as is? Unless absolutely needed, I'd prefer if you can remove them or move to sysfs. Well, my helper provides info on control and status registers flags (just like rtc-isl1208.c does), which are useful mainly for debug I guess. If this can help pushing things forward, I will send a v7 later today w/ the .proc helper removed from the patch. Why not convert to debugfs? thx, Jason. -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 01:09:40PM -0500, Jason Cooper wrote: On Thu, Dec 19, 2013 at 07:05:49PM +0100, Arnaud Ebalard wrote: Hi, Alessandro Zummo a.zu...@towertech.it writes: Do you want me to send a v7 w/ the .proc helper removed or leave things as they are and Ack the patch as is? Unless absolutely needed, I'd prefer if you can remove them or move to sysfs. Well, my helper provides info on control and status registers flags (just like rtc-isl1208.c does), which are useful mainly for debug I guess. If this can help pushing things forward, I will send a v7 later today w/ the .proc helper removed from the patch. Why not convert to debugfs? Separate follow-on patch, maybe, to keep things going ? Guenter -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 11:48:37AM -0800, Guenter Roeck wrote: On Thu, Dec 19, 2013 at 01:09:40PM -0500, Jason Cooper wrote: On Thu, Dec 19, 2013 at 07:05:49PM +0100, Arnaud Ebalard wrote: Hi, Alessandro Zummo a.zu...@towertech.it writes: Do you want me to send a v7 w/ the .proc helper removed or leave things as they are and Ack the patch as is? Unless absolutely needed, I'd prefer if you can remove them or move to sysfs. Well, my helper provides info on control and status registers flags (just like rtc-isl1208.c does), which are useful mainly for debug I guess. If this can help pushing things forward, I will send a v7 later today w/ the .proc helper removed from the patch. Why not convert to debugfs? Separate follow-on patch, maybe, to keep things going ? Sure. thx, Jason. -- 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: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
Hi, Alessandro Zummo a.zu...@towertech.it writes: On Thu, 19 Dec 2013 11:46:24 -0500 Jason Cooper ja...@lakedaemon.net wrote: In the long term, should we seek out a co-maintainer for drivers/rtc? Can anyone get a hold of Alessandro to get his opinion on this? I'd surely appreciate if someone can take some time to give a look to the patches. Most of them go thru subsystem's tree and, as far as I can see, I saw very relevant comments and fixes in all those years. While I am at it, I wonder if you can give me some directions on the following to add back alarm support to the ISL12057 on the specific hardware I have. All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which is used as main RTC clock but can also provide alarm. But the alarm interrupt line of the chip is *not* connected to the SoC. It is connected to some power component and can be used to wake up the NAS when it is completely off and the alarm rings. To me this kind of setup seems logical but it does not seem to be directly supported by current RTC logic: - first, I cannot test an interrupt handler implementation I had written as the SoC will never receive any interrupt. This limits my ability to provide one to the driver. - what can/should be done in my .dts file to indicate that the device does not have any IRQ line connected (and hence no interrupt handler) to the SoC but still supports an alarm. As a side note, the implementation I had was a working one on my hardware (i.e. was able to wake up the device at a given time) but I had to remove alarm code to get a basic driver accepted upstream. To be honest, I tried and understand what RTC subsystem expects from documentation and code w/o success. Any help appreciated on that topic. Cheers, a+ -- 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: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 06:46:18PM +0100, Arnaud Ebalard wrote: Hi, Jason Cooper ja...@lakedaemon.net writes: On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote: I have a very simple driver (support for reading and setting the time) for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it Acked and queued for v3.14. In v3.14, there should be at least three users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff for associated .dts changes. The -rc5 cutoff isn't a hard line. It's also mvebu-specific. eg, We need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we have time to get the pull request in. If it needs to go through mvebu/arm-soc, once it's posted, you're good. I understand. But I guess you will not (for valid reason) accept .dts changes to reference a rtc driver that is not on good track towards -next. This is the issue I try and solve. Just a subtle note here. If the binding is stabilized, I don't mind taking the dts changes. However, if we have time, I prefer to wait for the whole series to be hashed out. You never know which resolutions will end up revisiting the bindings you thought were good. :) So, it's technically not a requirement for the whole driver to be settled, but it is a good idea. thx, Jason. -- 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/
