From: Axel Haslam <ahaslam@baylibre.com> To: David Lechner <david@lechnology.com> Cc: Greg KH <gregkh@linuxfoundation.org>, Johan Hovold <johan@kernel.org>, robh+dt@kernel.org, Sekhar Nori <nsekhar@ti.com>, Alan Stern <stern@rowland.harvard.edu>, Kevin Hilman <khilman@baylibre.com>, Sergei Shtylyov <sshtylyov@ru.mvista.com>, Mark Brown <broonie@kernel.org>, Alexandre Bailon <abailon@baylibre.com>, linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH/RFT v2 12/17] USB: ochi-da8xx: Use a regulator for vbus/overcurrent Date: Tue, 25 Oct 2016 19:32:39 +0200 [thread overview] Message-ID: <CAKXjFTNrmmP++_xRq74G0Kx52R5w5TjTRukC=uB7rGwz8+EqUQ@mail.gmail.com> (raw) In-Reply-To: <09a4391e-63b6-1622-f964-4aff0ecae87c@lechnology.com> On Tue, Oct 25, 2016 at 6:53 PM, David Lechner <david@lechnology.com> wrote: > On 10/25/2016 03:24 AM, Axel Haslam wrote: >> >> On Tue, Oct 25, 2016 at 3:39 AM, David Lechner <david@lechnology.com> >> wrote: >>> >>> On 10/24/2016 11:46 AM, ahaslam@baylibre.com wrote: >>>> >>>> >>>> From: Axel Haslam <ahaslam@baylibre.com> >>>> >>>> Currently, the da8xx ohci driver uses a set of gpios and callbacks in >>>> board files to handle vbus and overcurrent irqs form the power supply. >>>> However, this does not play nice when moving to a DT based boot were >>>> we wont have board files. >>>> >>>> Instead of requesting and handling the gpio, use the regulator framework >>>> to take care of enabling and disabling vbus power. >>>> This has the benefit >>>> that we dont need to pass any more platform data to the driver: >>>> >>>> These will be handled by the regulator framework: >>>> set_power -> regulator_enable/regulator_disable >>>> get_power -> regulator_is_enabled >>>> get_oci -> regulator_get_mode >>>> ocic_notify -> regulator notification >>>> >>>> We can keep the default potpgt and use the regulator start delay >>>> instead: >>>> potpgt -> regulator startup delay time >>>> >>>> The hawk board does not have a GPIO/OVERCURRENT gpio to control vbus, >>>> (they should not have been decleared/reserved) so, just remove those >>>> definitions from the hwk board file. >>>> >>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com> >>>> --- >>> >>> >>> >>> >>> How do you recover after an overcurrent event? >>> >>> I have configured a fixed-regulator using device-tree, but similar to the >>> configuration in the board files here. However, when I shorted out the >>> VBUS >>> and caused an overcurrent event, I see nothing in the kernel log saying >>> that >>> there was an overcurrent event and after I remove the short, the >>> regulator >>> is never turned back on. >>> >>> >> >> You should have the patch to fix gpiolib, and you should declare the >> over current gpio on the regulator as such: >> (if the pin is enabled high you should add oc-active-high); >> >> vbus_fixed: fixed-regulator-vbus { >> compatible = "regulator-fixed"; >> gpio = <&gpio 109 0>; >> oc-gpio = <&gpio 36 0>; >> regulator-boot-on; >> enable-active-high; >> regulator-name = "vbus"; >> regulator-min-microvolt = <5000000>; >> regulator-max-microvolt = <5000000>; >> }; >> >> >> Question: Do you see that the over current gpio was requested >> in debugfs/gpio? and, do you see the interrupt in /proc/interrupts? >> >> If you unplug and plug in back the usb device it should work again. >> also you can unbind and bind it should also start to work: >> something like: >> >> echo usb1 >/sys/bus/usb/drivers/usb/unbind >> echo usb1 >/sys/bus/usb/drivers/usb/bind >> >> > > I have added oc-active-high and I get different results, but it is still not > quite right. When I short the VBUS, I can see that my overcurrent gpio > changes state. However, the driver does not turn of the VBUS. When I remove > the short, I get an overcurrent error in the kernel log. I would expect this > when I create the short, not when I remove it. I also tried adding > GPIO_ACTIVE_LOW to the oc-gpio, but this did not change the behavior. In > either case, the oc_gpio shows as high under normal conditions, so perhaps > there is a problem with the gpio-davinci driver not picking up > GPIO_ACTIVE_LOW from the device tree. > > > My regulator is basically the same. My device just uses different gpios. > > vbus_reg: vbus-reg { > compatible = "regulator-fixed"; > pinctrl-names = "default"; > pinctrl-0 = <&usb11_pins>; > gpio = <&gpio 101 GPIO_ACTIVE_LOW>; > oc-gpio = <&gpio 99 0>; > enable-active-high; > oc-active-high; > regulator-name = "vbus"; > regulator-min-microvolt = <5000000>; > regulator-max-microvolt = <5000000>; > } > > > It seems to me though that I should not have oc-active-high since under > normal conditions, the oc_gpio is high and during an overcurrent event, the in my board the over current gpio is active low too, i was just mentiontioning to add that in case yours was not. > oc_gpio is low. Double-checking the behavior without oc-active-high, I see > that the vbus gpio is turned off in response to the overcurrent event, but I > don't get the overcurrent message in the kernel log. Perhaps this is because > as soon as there is an overcurrent event the vbus turns off and the oc_gpio > returns to normal before the usb driver has a chance to poll the overcurrent > state? Perhaps. i dont have a board that has overcurrent, or that i can switch vbus off. what is exactly the log you are refering to? im wondering, was the behavior different before the patches? it should be the same without the patches. > > Also, unplugging the device and plugging it back in does nothing. Unbinding > and binding the driver does work, but that does not seem like a very nice > way to have to recover from an overcurrent event. im guessing that unplug and plug wont work as vbus is gone and we cannot detect it anymore (contrary to my setup were i always have vbus) sorry for suggesting that before. we could recover vbus automatically form the notification, (when the over-current condition disappears) but then im afraid we might oscillate, even if we retry after some timeout. so perhaps bind/unbind is the right thing to do, as it requires the user to correct the problem. I dont know if there is a better solution. > > >
WARNING: multiple messages have this Message-ID (diff)
From: ahaslam@baylibre.com (Axel Haslam) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH/RFT v2 12/17] USB: ochi-da8xx: Use a regulator for vbus/overcurrent Date: Tue, 25 Oct 2016 19:32:39 +0200 [thread overview] Message-ID: <CAKXjFTNrmmP++_xRq74G0Kx52R5w5TjTRukC=uB7rGwz8+EqUQ@mail.gmail.com> (raw) In-Reply-To: <09a4391e-63b6-1622-f964-4aff0ecae87c@lechnology.com> On Tue, Oct 25, 2016 at 6:53 PM, David Lechner <david@lechnology.com> wrote: > On 10/25/2016 03:24 AM, Axel Haslam wrote: >> >> On Tue, Oct 25, 2016 at 3:39 AM, David Lechner <david@lechnology.com> >> wrote: >>> >>> On 10/24/2016 11:46 AM, ahaslam at baylibre.com wrote: >>>> >>>> >>>> From: Axel Haslam <ahaslam@baylibre.com> >>>> >>>> Currently, the da8xx ohci driver uses a set of gpios and callbacks in >>>> board files to handle vbus and overcurrent irqs form the power supply. >>>> However, this does not play nice when moving to a DT based boot were >>>> we wont have board files. >>>> >>>> Instead of requesting and handling the gpio, use the regulator framework >>>> to take care of enabling and disabling vbus power. >>>> This has the benefit >>>> that we dont need to pass any more platform data to the driver: >>>> >>>> These will be handled by the regulator framework: >>>> set_power -> regulator_enable/regulator_disable >>>> get_power -> regulator_is_enabled >>>> get_oci -> regulator_get_mode >>>> ocic_notify -> regulator notification >>>> >>>> We can keep the default potpgt and use the regulator start delay >>>> instead: >>>> potpgt -> regulator startup delay time >>>> >>>> The hawk board does not have a GPIO/OVERCURRENT gpio to control vbus, >>>> (they should not have been decleared/reserved) so, just remove those >>>> definitions from the hwk board file. >>>> >>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com> >>>> --- >>> >>> >>> >>> >>> How do you recover after an overcurrent event? >>> >>> I have configured a fixed-regulator using device-tree, but similar to the >>> configuration in the board files here. However, when I shorted out the >>> VBUS >>> and caused an overcurrent event, I see nothing in the kernel log saying >>> that >>> there was an overcurrent event and after I remove the short, the >>> regulator >>> is never turned back on. >>> >>> >> >> You should have the patch to fix gpiolib, and you should declare the >> over current gpio on the regulator as such: >> (if the pin is enabled high you should add oc-active-high); >> >> vbus_fixed: fixed-regulator-vbus { >> compatible = "regulator-fixed"; >> gpio = <&gpio 109 0>; >> oc-gpio = <&gpio 36 0>; >> regulator-boot-on; >> enable-active-high; >> regulator-name = "vbus"; >> regulator-min-microvolt = <5000000>; >> regulator-max-microvolt = <5000000>; >> }; >> >> >> Question: Do you see that the over current gpio was requested >> in debugfs/gpio? and, do you see the interrupt in /proc/interrupts? >> >> If you unplug and plug in back the usb device it should work again. >> also you can unbind and bind it should also start to work: >> something like: >> >> echo usb1 >/sys/bus/usb/drivers/usb/unbind >> echo usb1 >/sys/bus/usb/drivers/usb/bind >> >> > > I have added oc-active-high and I get different results, but it is still not > quite right. When I short the VBUS, I can see that my overcurrent gpio > changes state. However, the driver does not turn of the VBUS. When I remove > the short, I get an overcurrent error in the kernel log. I would expect this > when I create the short, not when I remove it. I also tried adding > GPIO_ACTIVE_LOW to the oc-gpio, but this did not change the behavior. In > either case, the oc_gpio shows as high under normal conditions, so perhaps > there is a problem with the gpio-davinci driver not picking up > GPIO_ACTIVE_LOW from the device tree. > > > My regulator is basically the same. My device just uses different gpios. > > vbus_reg: vbus-reg { > compatible = "regulator-fixed"; > pinctrl-names = "default"; > pinctrl-0 = <&usb11_pins>; > gpio = <&gpio 101 GPIO_ACTIVE_LOW>; > oc-gpio = <&gpio 99 0>; > enable-active-high; > oc-active-high; > regulator-name = "vbus"; > regulator-min-microvolt = <5000000>; > regulator-max-microvolt = <5000000>; > } > > > It seems to me though that I should not have oc-active-high since under > normal conditions, the oc_gpio is high and during an overcurrent event, the in my board the over current gpio is active low too, i was just mentiontioning to add that in case yours was not. > oc_gpio is low. Double-checking the behavior without oc-active-high, I see > that the vbus gpio is turned off in response to the overcurrent event, but I > don't get the overcurrent message in the kernel log. Perhaps this is because > as soon as there is an overcurrent event the vbus turns off and the oc_gpio > returns to normal before the usb driver has a chance to poll the overcurrent > state? Perhaps. i dont have a board that has overcurrent, or that i can switch vbus off. what is exactly the log you are refering to? im wondering, was the behavior different before the patches? it should be the same without the patches. > > Also, unplugging the device and plugging it back in does nothing. Unbinding > and binding the driver does work, but that does not seem like a very nice > way to have to recover from an overcurrent event. im guessing that unplug and plug wont work as vbus is gone and we cannot detect it anymore (contrary to my setup were i always have vbus) sorry for suggesting that before. we could recover vbus automatically form the notification, (when the over-current condition disappears) but then im afraid we might oscillate, even if we retry after some timeout. so perhaps bind/unbind is the right thing to do, as it requires the user to correct the problem. I dont know if there is a better solution. > > >
next prev parent reply other threads:[~2016-10-25 17:33 UTC|newest] Thread overview: 176+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-10-24 16:46 [PATCH/RFT v2 00/17] Add DT support for ohci-da8xx ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` [PATCH/RFT v2 01/17] ARM: davinci: da8xx: add usb phy clocks ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-25 8:10 ` Sekhar Nori 2016-10-25 8:10 ` Sekhar Nori 2016-10-25 8:10 ` Sekhar Nori 2016-10-25 9:37 ` Axel Haslam 2016-10-25 9:37 ` Axel Haslam 2016-10-25 9:37 ` Axel Haslam 2016-10-25 10:17 ` Sekhar Nori 2016-10-25 10:17 ` Sekhar Nori 2016-10-25 10:17 ` Sekhar Nori 2016-10-25 15:53 ` David Lechner 2016-10-25 15:53 ` David Lechner 2016-10-25 15:53 ` David Lechner 2016-10-26 8:56 ` Sekhar Nori 2016-10-26 8:56 ` Sekhar Nori 2016-10-26 8:56 ` Sekhar Nori 2016-10-24 16:46 ` [PATCH/RFT v2 03/17] ARM: davinci: da8xx: Add USB PHY " ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-25 9:18 ` Sekhar Nori 2016-10-25 9:18 ` Sekhar Nori 2016-10-25 9:18 ` Sekhar Nori 2016-10-25 9:37 ` Axel Haslam 2016-10-25 9:37 ` Axel Haslam 2016-10-25 9:37 ` Axel Haslam 2016-10-24 16:46 ` [PATCH/RFT v2 04/17] ARM: DTS: da850: Add cfgchip syscon node ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam 2016-10-24 16:46 ` [PATCH/RFT v2 05/17] ARM: DTS: da850: Add usb phy node ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam 2016-10-24 16:46 ` [PATCH/RFT v2 06/17] ARM: davinci: da8xx: Fix some redefined symbol warnings ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-25 10:03 ` Sekhar Nori 2016-10-25 10:03 ` Sekhar Nori 2016-10-25 10:03 ` Sekhar Nori 2016-10-25 12:14 ` Alexandre Bailon 2016-10-25 12:14 ` Alexandre Bailon 2016-10-25 12:14 ` Alexandre Bailon 2016-10-24 16:46 ` [PATCH/RFT v2 07/17] ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam 2016-10-25 2:53 ` David Lechner 2016-10-25 2:53 ` David Lechner 2016-10-25 10:01 ` Axel Haslam 2016-10-25 10:01 ` Axel Haslam 2016-10-25 10:12 ` Sekhar Nori 2016-10-25 10:12 ` Sekhar Nori 2016-10-25 10:12 ` Sekhar Nori 2016-10-25 16:05 ` David Lechner 2016-10-25 16:05 ` David Lechner 2016-10-25 16:05 ` David Lechner 2016-10-26 9:30 ` Sekhar Nori 2016-10-26 9:30 ` Sekhar Nori 2016-10-26 9:30 ` Sekhar Nori 2016-10-24 16:46 ` [PATCH/RFT v2 08/17] ARM: davinci: hawk: add full constraints for ohci plat boot ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-25 10:28 ` Sekhar Nori 2016-10-25 10:28 ` Sekhar Nori 2016-10-25 10:28 ` Sekhar Nori 2016-10-25 10:31 ` Axel Haslam 2016-10-25 10:31 ` Axel Haslam 2016-10-25 10:31 ` Axel Haslam 2016-10-24 16:46 ` [PATCH/RFT v2 09/17] regulator: fixed: Add over current event ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-24 17:43 ` Mark Brown 2016-10-24 17:43 ` Mark Brown 2016-10-24 17:43 ` Mark Brown 2016-10-24 17:53 ` Axel Haslam 2016-10-24 17:53 ` Axel Haslam 2016-10-24 17:53 ` Mark Brown 2016-10-24 17:53 ` Mark Brown 2016-10-24 17:53 ` Mark Brown 2016-10-24 18:11 ` Axel Haslam 2016-10-24 18:11 ` Axel Haslam 2016-10-24 18:11 ` Axel Haslam 2016-10-24 18:19 ` Mark Brown 2016-10-24 18:19 ` Mark Brown 2016-10-25 12:55 ` Axel Haslam 2016-10-25 12:55 ` Axel Haslam 2016-10-25 14:33 ` Mark Brown 2016-10-25 14:33 ` Mark Brown 2016-10-25 14:57 ` Axel Haslam 2016-10-25 14:57 ` Axel Haslam 2016-10-25 15:07 ` Axel Haslam 2016-10-25 15:07 ` Axel Haslam 2016-10-30 20:42 ` Rob Herring 2016-10-30 20:42 ` Rob Herring 2016-10-24 16:46 ` [PATCH/RFT v2 10/17] USB: da8xx: use flag instead of bitmask for over current change ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-24 16:46 ` [PATCH/RFT v2 11/17] USB: OHCI: make ohci-da8xx a separate driver ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-25 0:38 ` David Lechner 2016-10-25 0:38 ` David Lechner 2016-10-25 0:38 ` David Lechner 2016-10-25 7:39 ` Axel Haslam 2016-10-25 7:39 ` Axel Haslam 2016-10-25 7:39 ` Axel Haslam 2016-10-25 16:12 ` David Lechner 2016-10-25 16:12 ` David Lechner 2016-10-25 16:12 ` David Lechner 2016-10-25 16:21 ` Axel Haslam 2016-10-25 16:21 ` Axel Haslam 2016-10-25 16:21 ` Axel Haslam 2016-10-25 16:24 ` David Lechner 2016-10-25 16:24 ` David Lechner 2016-10-25 16:24 ` David Lechner 2016-10-24 16:46 ` [PATCH/RFT v2 12/17] USB: ochi-da8xx: Use a regulator for vbus/overcurrent ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-25 1:39 ` David Lechner 2016-10-25 1:39 ` David Lechner 2016-10-25 1:39 ` David Lechner 2016-10-25 8:24 ` Axel Haslam 2016-10-25 8:24 ` Axel Haslam 2016-10-25 8:24 ` Axel Haslam 2016-10-25 16:53 ` David Lechner 2016-10-25 16:53 ` David Lechner 2016-10-25 16:53 ` David Lechner 2016-10-25 17:32 ` Axel Haslam [this message] 2016-10-25 17:32 ` Axel Haslam 2016-10-25 10:43 ` Sekhar Nori 2016-10-25 10:43 ` Sekhar Nori 2016-10-25 10:43 ` Sekhar Nori 2016-10-25 10:52 ` Axel Haslam 2016-10-25 10:52 ` Axel Haslam 2016-10-25 10:52 ` Axel Haslam 2016-10-24 16:46 ` [PATCH/RFT v2 13/17] USB: da8xx: use ohci priv data instead of globals ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-25 1:12 ` David Lechner 2016-10-25 1:12 ` David Lechner 2016-10-25 1:12 ` David Lechner 2016-10-25 9:56 ` Axel Haslam 2016-10-25 9:56 ` Axel Haslam 2016-10-24 16:46 ` [PATCH/RFT v2 14/17] ARM: davinci: register the usb20_phy clock on the DT file ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-24 16:46 ` [PATCH/RFT v2 15/17] usb: host: ohci-da8xx: Add devicetree bindings documentation ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-25 1:02 ` David Lechner 2016-10-25 1:02 ` David Lechner 2016-10-25 1:02 ` David Lechner 2016-10-25 9:56 ` Axel Haslam 2016-10-25 9:56 ` Axel Haslam 2016-10-25 9:56 ` Axel Haslam 2016-10-24 16:46 ` [PATCH/RFT v2 16/17] USB: ohci-da8xx: Allow probing from DT ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-24 16:46 ` ahaslam-rdvid1DuHRBWk0Htik3J/w 2016-10-25 0:53 ` David Lechner 2016-10-25 0:53 ` David Lechner 2016-10-25 0:53 ` David Lechner 2016-10-25 8:10 ` Axel Haslam 2016-10-25 8:10 ` Axel Haslam 2016-10-24 16:46 ` [PATCH/RFT v2 17/17] ARM: dts: da850: add usb device node ahaslam 2016-10-24 16:46 ` ahaslam at baylibre.com 2016-10-25 0:48 ` David Lechner 2016-10-25 0:48 ` David Lechner 2016-10-25 0:48 ` David Lechner 2016-10-25 8:03 ` Axel Haslam 2016-10-25 8:03 ` Axel Haslam 2016-10-25 8:03 ` Axel Haslam 2016-10-25 10:55 ` [PATCH/RFT v2 00/17] Add DT support for ohci-da8xx Sekhar Nori 2016-10-25 10:55 ` Sekhar Nori 2016-10-25 10:55 ` Sekhar Nori
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKXjFTNrmmP++_xRq74G0Kx52R5w5TjTRukC=uB7rGwz8+EqUQ@mail.gmail.com' \ --to=ahaslam@baylibre.com \ --cc=abailon@baylibre.com \ --cc=broonie@kernel.org \ --cc=david@lechnology.com \ --cc=devicetree@vger.kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=johan@kernel.org \ --cc=khilman@baylibre.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=nsekhar@ti.com \ --cc=robh+dt@kernel.org \ --cc=sshtylyov@ru.mvista.com \ --cc=stern@rowland.harvard.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.