From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90C28C43441 for ; Tue, 13 Nov 2018 21:54:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2263820896 for ; Tue, 13 Nov 2018 21:54:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ejuX9FDF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2263820896 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730782AbeKNHyc (ORCPT ); Wed, 14 Nov 2018 02:54:32 -0500 Received: from mail-ua1-f66.google.com ([209.85.222.66]:37722 "EHLO mail-ua1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726022AbeKNHyb (ORCPT ); Wed, 14 Nov 2018 02:54:31 -0500 Received: by mail-ua1-f66.google.com with SMTP id u19so4932231uae.4; Tue, 13 Nov 2018 13:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vjJHPxd2xEFo+/+ErU1OFCTFpKQcDZm/g53cmtbx70g=; b=ejuX9FDFA47NZ/zU9LERpEUsdomplT/za47LCrqOuox9cLXet6xtYB3X6mXtYbGNi1 EfQsE2x53q8NH/7xCFf21vvMBzu3bHHi+c1HEob2Zggx3yONWcE4U5PwFWIew//YSLTA gV9+vwjxLYZteSdDqT3Il1r9ya0pP8A2AMFNyG7NDeli74E8Tbei8eOAo9/iuxGRD5mz oeRSlkJzTGP7BzJLj4qs9ZVUFA0HMLGXIx+TsDEOaDYc3rlozah+5yLOdSB7GodUBbdO Le9P73FmlbVroIfH0y7FxCNnc+ZW5sznIPkWyPzHzlOo7rnsumRsh8B0/zFSEGzGbWRv 9f3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vjJHPxd2xEFo+/+ErU1OFCTFpKQcDZm/g53cmtbx70g=; b=AKA43QT5vskVA/AbJHYnNxNRcjDuSlVgqR1WvIl53Vw5eeieUV3GqvFwE70gSGt0jB F24Ql+H5S/B95/gNA78PE1j1qh3+JiUucGsMXGZVJcs2CzKjFDqPERQtYQV/lRoaxfOM IiSR22sK7VBtXxHGWckJsQvsf52jr2RKGZSfn/BVUIRRvDVyxWIe3y6upeHkQFtPbxQH UM+9iMbTYN8QfWVMpcJ4xMuc2IYBoH2ED4xQahZX9gh+2P04A86xAv1PRj08TaNxm7dW h/wRpFALq5jDLsvTmn39oMBcrK7WYj/AhIDnLRKQBHZaanKj//KpMCVWZyIyazZV8HNV T42A== X-Gm-Message-State: AGRZ1gIUMM9EUUB6nXEqdGvVX2djWI0XiWlvLr2tNAdA+z44Gl9MllcV PZXnx9FjqhbcB8PN9oNUJIDJRxfSgjNZ6/ZFYGo= X-Google-Smtp-Source: AJdET5cSibKtPvPuS+BaaoyeUaoAYaRB1WE6xTnSShz3uUuLOlldIRCuxGpj+3inW1X7Z8HZkwcTplPgbHPvaO42pOY= X-Received: by 2002:a9f:3703:: with SMTP id z3mr3356958uad.86.1542146062611; Tue, 13 Nov 2018 13:54:22 -0800 (PST) MIME-Version: 1.0 References: <16a80878-58f7-1584-058e-0e0e49da61cb@gmail.com> <45134862-4b72-be72-533c-942c2bf70400@broadcom.com> <20181112174532.GA14682@bogus> In-Reply-To: <20181112174532.GA14682@bogus> From: Alan Cooper Date: Tue, 13 Nov 2018 16:54:18 -0500 Message-ID: Subject: Re: [PATCH V3 4/6] usb: ohci-platform: Add support for Broadcom STB SoC's To: Rob Herring Cc: Florian Fainelli , al.cooper@broadcom.com, Alan Stern , ": Linux Kernel Mailing List" , Alban Bedel , Alex Elder , Andrew Morton , Arnd Bergmann , Avi Fishman , bcm-kernel-feedback-list@broadcom.com, Bjorn Andersson , chunfeng yun , "David S. Miller" , DTML , Dmitry Osipenko , Greg Kroah-Hartman , "Gustavo A. R. Silva" , Hans de Goede , James Hogan , Jianguo Sun , Johan Hovold , Kees Cook , USB list , Lu Baolu , Mark Rutland , Martin Blumenstingl , Mathias Nyman , Mathias Nyman , Mauro Carvalho Chehab , Rishabh Bhatnagar , Roger Quadros Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 12, 2018 at 6:37 PM Rob Herring wrote: > > On Wed, Nov 07, 2018 at 10:11:59AM -0800, Florian Fainelli wrote: > > On 11/7/2018 9:40 AM, Al Cooper wrote: > > > On 11/7/18 12:29 PM, Florian Fainelli wrote: > > >> On 11/7/18 8:27 AM, Alan Stern wrote: > > >>> On Wed, 7 Nov 2018, Al Cooper wrote: > > >>> > > >>>> On 11/7/18 10:23 AM, Alan Stern wrote: > > >>>>> On Tue, 6 Nov 2018, Florian Fainelli wrote: > > >>>>> > > >>>>>> On 11/6/18 1:40 PM, Al Cooper wrote: > > >>>>>>> On 11/6/18 11:08 AM, Alan Stern wrote: > > >>>>>>>> On Mon, 5 Nov 2018, Al Cooper wrote: > > >>>>>>>> > > >>>>>>>>> Add support for Broadcom STB SoC's to the ohci platform driver. > > >>>>>>>>> > > >>>>>>>>> Signed-off-by: Al Cooper > > >>>>>>>>> --- > > >>>>>>>> > > >>>>>>>>> @@ -177,6 +189,8 @@ static int ohci_platform_probe(struct > > >>>>>>>>> platform_device *dev) > > >>>>>>>>> ohci->flags |= OHCI_QUIRK_FRAME_NO; > > >>>>>>>>> if (pdata->num_ports) > > >>>>>>>>> ohci->num_ports = pdata->num_ports; > > >>>>>>>>> + if (pdata->suspend_without_phy_exit) > > >>>>>>>>> + hcd->suspend_without_phy_exit = 1; > > >>>>>>>> > > >>>>>>>> Sorry if I missed this in the earlier discussions... Is there any > > >>>>>>>> possibility of adding a DT binding that could express this > > >>>>>>>> requirement, > > >>>>>>>> instead of putting it in the platform data? > > >>>>>>>> > > >>>>>>>> Alan Stern > > >>>>>>>> > > >>>>>>> > > >>>>>>> Alan, > > >>>>>>> > > >>>>>>> That was my original approach but internal review suggested that > > >>>>>>> I use > > >>>>>>> pdata instead. Below is my original patch for: > > >>>>>> > > >>>>>> And the reason for that suggestion was really because it was > > >>>>>> percevied > > >>>>>> as encoding a driver behavior as a Device Tree property as opposed to > > >>>>>> describing something that was inherently and strictly a hardware > > >>>>>> behavior (therefore suitable for Device Tree). > > >>>>> > > >>>>> Right. The best way to approach this problem is to identify and > > >>>>> characterize the hardware behavior which makes this override > > >>>>> necessary. > > >>>>> Then _that_ can be added to DT, since it will be a property of the > > >>>>> hardware rather than of the driver. > > >>>>> > > >>>>>>> Add the ability to skip calling the PHY's exit routine on suspend > > >>>>>>> and the PHY's init routine on resume. This is to handle a USB PHY > > >>>>>>> that should have it's power_off function called on suspend but > > >>>>>>> cannot > > >>>>>>> have it's exit function called because on exit it will disable the > > >>>>>>> PHY to the point where register accesses to the Host Controllers > > >>>>>>> using the PHY will be disabled and the host drivers will crash. > > >>>>> > > >>>>> What's special about this PHY? Why does the exit function mess the > > >>>>> PHY > > >>>>> up? Or to put it another way, why doesn't the exit function mess up > > >>>>> other PHYs in the same way? > > >>>>> > > >>>>> For that matter, can we change the code so that suspend doesn't call > > >>>>> the exit function for _any_ PHY? Will just calling the power_off > > >>>>> function be good enough? If not, then why not? > > >>>>> > > >>>>> Alan Stern > > >>>>> > > >>>> > > >>>> In our USB hardware the USB PHY supplies a clock for the EHCI/OHCI and > > >>>> XHCI host controllers and if the PHY is totally shut down the EHCI, > > >>>> OHCI > > >>>> and XHCI registers will cause an exception if accessed and cause the > > >>>> EHCI, OHCI and XHCI drivers to crash. There is always talk of fixing > > >>>> this in the hardware by adding an aux clock that will takeover when the > > >>>> PHY clock is shut down, but this hasn't happened yet. It seems like > > >>>> "exit on suspend" still makes sense on systems that don't have this > > >>>> problem (additional power savings?) so removing the exit on suspend for > > >>>> all systems is not a good idea. > > >>> > > >>> Then in theory you should be able to add a Device Tree property which > > >>> says that the PHY provides a clock for the USB host controller. That > > >>> is strictly a property of the hardware; it has nothing to do with the > > >>> driver. Therefore it is appropriate for DT. > > >> > > >> The very compatible string that is being allocated/defined for this > > >> controller carries that information already, that is, if you probe a > > >> "brcm,bcm7445-ohci" compatible then that means the controller has a > > >> dependency on the PHY to supply its clock. > > >> > > >> Adding a property vs. keying on the compatible string makes sense if you > > >> know there is at least a second consumer of that property (unless we > > >> make it a broadcom specific property, in which case, it really is > > >> redundant with the compatible string). > > >> > > >> Anyway, my grudge with that property was the name chosen initially, > > >> which included an action to be performed by an implementation as opposed > > >> to something purely descriptive. E.g: 'phy-supplies-clock' might be okay. > > >> > > >>> > > >>> Wouldn't this solve your issue? > > >> > > >> It would not change much except that there is no need to much with > > >> ohci-platform.c anymore, but ultimately that property needs to be read > > >> by ohci-hcd.c and acted on, which would likely lead to the same amount > > >> of changes as those present in patch #2 currently. > > >> > > > We also need this functionality in the EHCI and XHCI drivers and it's > > > not the ohci-hcd.c module that needs to know, it's the core/phy.c module > > > called from core/hcd.c. > > > > So in that regard the Device Tree property would actually scale a bit > > better in that you would no longer need to modify the various > > *hci-plat*.c files, if that is the way to go, then sure. > > Sounds like the phy needs to be a clock provider to the USB controller. > Maybe that's a bit of overkill, but would be the most accurate. > > Otherwise, my preference is using the compatible string. IOW, we already > have properties to handle this. If you don't want to use them, then use > compatible rather than inventing something new and custom. My previous commit used the compatible string to set the HCD flag instead of a device tree property, but Alan Stern ask me to use a DT binding instead. This has the advantage of having the code in one place in the phy.c module instead of having to add it to the OHCI, EHCI and XHCI platform drivers. > > At least last time I looked, there's a lack of support in the PHY API to > handle various handshakes needed between phys and controllers like this. > It's fairly easy for the controller to fetch info from a phy node, but > the opposite is not so easy. It seems to me some API for controllers to > set flags in the phy driver is needed. The Generic PHY subsystem allows the PHY provider to export phy_power_on/phy_power_off and phy_init/phy_exit functions for use by the PHY consumer. The exact functionality of these routines seems to vary among the different PHY provider drivers. The Broadcom USB PHY driver expects the phy_power_on/phy_power_off to be used on suspend/resume and the phy_init/phy_exit to be used by the consumer driver's probe/remove routines. The new USB PHY consumer code does not do this, instead it calls both power_off AND exit for both suspend (not wakable) and remove. If you look at other PHY provider/consumer implementations in the kernel tree you'll find examples of both these methods but there are more examples that behave like the Broadcom PHY. What I was trying to do was to use a DT property to tell the USB PHY consumer code which method to use. I guess the problem is that the current generic PHY api only allows the consumer to put the PHY in 1 of 3 states, EXIT, OFF or ON. The current USB PHY consumer code is using OFF for "suspend with wakeup" and EXIT for "suspend without wakeup". The Broadcom PHY driver wants OFF for either "suspend with wakeup" or "suspend without wakeup" and EXIT when there are no consumers using the PHY. If the PHY API allowed for 4 states, EXIT, OFF_NOT_WAKABLE, OFF_WAKABLE and ON then the individual PHY provider could hide the differences, but this seems hard to retrofit into the PHY subsystem. Al > > Rob > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cooper Subject: Re: [PATCH V3 4/6] usb: ohci-platform: Add support for Broadcom STB SoC's Date: Tue, 13 Nov 2018 16:54:18 -0500 Message-ID: References: <16a80878-58f7-1584-058e-0e0e49da61cb@gmail.com> <45134862-4b72-be72-533c-942c2bf70400@broadcom.com> <20181112174532.GA14682@bogus> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20181112174532.GA14682@bogus> Sender: linux-kernel-owner@vger.kernel.org To: Rob Herring Cc: Florian Fainelli , al.cooper@broadcom.com, Alan Stern , ": Linux Kernel Mailing List" , Alban Bedel , Alex Elder , Andrew Morton , Arnd Bergmann , Avi Fishman , bcm-kernel-feedback-list@broadcom.com, Bjorn Andersson , chunfeng yun , "David S. Miller" , DTML , Dmitry Osipenko , Greg Kroah-Hartman , "Gustavo A. R. Silva" , Hans de Goede , James Hogan , Jianguo Sun List-Id: devicetree@vger.kernel.org On Mon, Nov 12, 2018 at 6:37 PM Rob Herring wrote: > > On Wed, Nov 07, 2018 at 10:11:59AM -0800, Florian Fainelli wrote: > > On 11/7/2018 9:40 AM, Al Cooper wrote: > > > On 11/7/18 12:29 PM, Florian Fainelli wrote: > > >> On 11/7/18 8:27 AM, Alan Stern wrote: > > >>> On Wed, 7 Nov 2018, Al Cooper wrote: > > >>> > > >>>> On 11/7/18 10:23 AM, Alan Stern wrote: > > >>>>> On Tue, 6 Nov 2018, Florian Fainelli wrote: > > >>>>> > > >>>>>> On 11/6/18 1:40 PM, Al Cooper wrote: > > >>>>>>> On 11/6/18 11:08 AM, Alan Stern wrote: > > >>>>>>>> On Mon, 5 Nov 2018, Al Cooper wrote: > > >>>>>>>> > > >>>>>>>>> Add support for Broadcom STB SoC's to the ohci platform driver. > > >>>>>>>>> > > >>>>>>>>> Signed-off-by: Al Cooper > > >>>>>>>>> --- > > >>>>>>>> > > >>>>>>>>> @@ -177,6 +189,8 @@ static int ohci_platform_probe(struct > > >>>>>>>>> platform_device *dev) > > >>>>>>>>> ohci->flags |= OHCI_QUIRK_FRAME_NO; > > >>>>>>>>> if (pdata->num_ports) > > >>>>>>>>> ohci->num_ports = pdata->num_ports; > > >>>>>>>>> + if (pdata->suspend_without_phy_exit) > > >>>>>>>>> + hcd->suspend_without_phy_exit = 1; > > >>>>>>>> > > >>>>>>>> Sorry if I missed this in the earlier discussions... Is there any > > >>>>>>>> possibility of adding a DT binding that could express this > > >>>>>>>> requirement, > > >>>>>>>> instead of putting it in the platform data? > > >>>>>>>> > > >>>>>>>> Alan Stern > > >>>>>>>> > > >>>>>>> > > >>>>>>> Alan, > > >>>>>>> > > >>>>>>> That was my original approach but internal review suggested that > > >>>>>>> I use > > >>>>>>> pdata instead. Below is my original patch for: > > >>>>>> > > >>>>>> And the reason for that suggestion was really because it was > > >>>>>> percevied > > >>>>>> as encoding a driver behavior as a Device Tree property as opposed to > > >>>>>> describing something that was inherently and strictly a hardware > > >>>>>> behavior (therefore suitable for Device Tree). > > >>>>> > > >>>>> Right. The best way to approach this problem is to identify and > > >>>>> characterize the hardware behavior which makes this override > > >>>>> necessary. > > >>>>> Then _that_ can be added to DT, since it will be a property of the > > >>>>> hardware rather than of the driver. > > >>>>> > > >>>>>>> Add the ability to skip calling the PHY's exit routine on suspend > > >>>>>>> and the PHY's init routine on resume. This is to handle a USB PHY > > >>>>>>> that should have it's power_off function called on suspend but > > >>>>>>> cannot > > >>>>>>> have it's exit function called because on exit it will disable the > > >>>>>>> PHY to the point where register accesses to the Host Controllers > > >>>>>>> using the PHY will be disabled and the host drivers will crash. > > >>>>> > > >>>>> What's special about this PHY? Why does the exit function mess the > > >>>>> PHY > > >>>>> up? Or to put it another way, why doesn't the exit function mess up > > >>>>> other PHYs in the same way? > > >>>>> > > >>>>> For that matter, can we change the code so that suspend doesn't call > > >>>>> the exit function for _any_ PHY? Will just calling the power_off > > >>>>> function be good enough? If not, then why not? > > >>>>> > > >>>>> Alan Stern > > >>>>> > > >>>> > > >>>> In our USB hardware the USB PHY supplies a clock for the EHCI/OHCI and > > >>>> XHCI host controllers and if the PHY is totally shut down the EHCI, > > >>>> OHCI > > >>>> and XHCI registers will cause an exception if accessed and cause the > > >>>> EHCI, OHCI and XHCI drivers to crash. There is always talk of fixing > > >>>> this in the hardware by adding an aux clock that will takeover when the > > >>>> PHY clock is shut down, but this hasn't happened yet. It seems like > > >>>> "exit on suspend" still makes sense on systems that don't have this > > >>>> problem (additional power savings?) so removing the exit on suspend for > > >>>> all systems is not a good idea. > > >>> > > >>> Then in theory you should be able to add a Device Tree property which > > >>> says that the PHY provides a clock for the USB host controller. That > > >>> is strictly a property of the hardware; it has nothing to do with the > > >>> driver. Therefore it is appropriate for DT. > > >> > > >> The very compatible string that is being allocated/defined for this > > >> controller carries that information already, that is, if you probe a > > >> "brcm,bcm7445-ohci" compatible then that means the controller has a > > >> dependency on the PHY to supply its clock. > > >> > > >> Adding a property vs. keying on the compatible string makes sense if you > > >> know there is at least a second consumer of that property (unless we > > >> make it a broadcom specific property, in which case, it really is > > >> redundant with the compatible string). > > >> > > >> Anyway, my grudge with that property was the name chosen initially, > > >> which included an action to be performed by an implementation as opposed > > >> to something purely descriptive. E.g: 'phy-supplies-clock' might be okay. > > >> > > >>> > > >>> Wouldn't this solve your issue? > > >> > > >> It would not change much except that there is no need to much with > > >> ohci-platform.c anymore, but ultimately that property needs to be read > > >> by ohci-hcd.c and acted on, which would likely lead to the same amount > > >> of changes as those present in patch #2 currently. > > >> > > > We also need this functionality in the EHCI and XHCI drivers and it's > > > not the ohci-hcd.c module that needs to know, it's the core/phy.c module > > > called from core/hcd.c. > > > > So in that regard the Device Tree property would actually scale a bit > > better in that you would no longer need to modify the various > > *hci-plat*.c files, if that is the way to go, then sure. > > Sounds like the phy needs to be a clock provider to the USB controller. > Maybe that's a bit of overkill, but would be the most accurate. > > Otherwise, my preference is using the compatible string. IOW, we already > have properties to handle this. If you don't want to use them, then use > compatible rather than inventing something new and custom. My previous commit used the compatible string to set the HCD flag instead of a device tree property, but Alan Stern ask me to use a DT binding instead. This has the advantage of having the code in one place in the phy.c module instead of having to add it to the OHCI, EHCI and XHCI platform drivers. > > At least last time I looked, there's a lack of support in the PHY API to > handle various handshakes needed between phys and controllers like this. > It's fairly easy for the controller to fetch info from a phy node, but > the opposite is not so easy. It seems to me some API for controllers to > set flags in the phy driver is needed. The Generic PHY subsystem allows the PHY provider to export phy_power_on/phy_power_off and phy_init/phy_exit functions for use by the PHY consumer. The exact functionality of these routines seems to vary among the different PHY provider drivers. The Broadcom USB PHY driver expects the phy_power_on/phy_power_off to be used on suspend/resume and the phy_init/phy_exit to be used by the consumer driver's probe/remove routines. The new USB PHY consumer code does not do this, instead it calls both power_off AND exit for both suspend (not wakable) and remove. If you look at other PHY provider/consumer implementations in the kernel tree you'll find examples of both these methods but there are more examples that behave like the Broadcom PHY. What I was trying to do was to use a DT property to tell the USB PHY consumer code which method to use. I guess the problem is that the current generic PHY api only allows the consumer to put the PHY in 1 of 3 states, EXIT, OFF or ON. The current USB PHY consumer code is using OFF for "suspend with wakeup" and EXIT for "suspend without wakeup". The Broadcom PHY driver wants OFF for either "suspend with wakeup" or "suspend without wakeup" and EXIT when there are no consumers using the PHY. If the PHY API allowed for 4 states, EXIT, OFF_NOT_WAKABLE, OFF_WAKABLE and ON then the individual PHY provider could hide the differences, but this seems hard to retrofit into the PHY subsystem. Al > > Rob > From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [V3,4/6] usb: ohci-platform: Add support for Broadcom STB SoC's From: Alan Cooper Message-Id: Date: Tue, 13 Nov 2018 16:54:18 -0500 To: Rob Herring Cc: Florian Fainelli , al.cooper@broadcom.com, Alan Stern , ": Linux Kernel Mailing List" , Alban Bedel , Alex Elder , Andrew Morton , Arnd Bergmann , Avi Fishman , bcm-kernel-feedback-list@broadcom.com, Bjorn Andersson , chunfeng yun , "David S. Miller" , DTML , Dmitry Osipenko , Greg Kroah-Hartman , "Gustavo A. R. Silva" , Hans de Goede , James Hogan , Jianguo Sun , Johan Hovold , Kees Cook , USB list , Lu Baolu , Mark Rutland , Martin Blumenstingl , Mathias Nyman , Mathias Nyman , Mauro Carvalho Chehab , Rishabh Bhatnagar , Roger Quadros List-ID: T24gTW9uLCBOb3YgMTIsIDIwMTggYXQgNjozNyBQTSBSb2IgSGVycmluZyA8cm9iaEBrZXJuZWwu b3JnPiB3cm90ZToKPgo+IE9uIFdlZCwgTm92IDA3LCAyMDE4IGF0IDEwOjExOjU5QU0gLTA4MDAs IEZsb3JpYW4gRmFpbmVsbGkgd3JvdGU6Cj4gPiBPbiAxMS83LzIwMTggOTo0MCBBTSwgQWwgQ29v cGVyIHdyb3RlOgo+ID4gPiBPbiAxMS83LzE4IDEyOjI5IFBNLCBGbG9yaWFuIEZhaW5lbGxpIHdy b3RlOgo+ID4gPj4gT24gMTEvNy8xOCA4OjI3IEFNLCBBbGFuIFN0ZXJuIHdyb3RlOgo+ID4gPj4+ IE9uIFdlZCwgNyBOb3YgMjAxOCwgQWwgQ29vcGVyIHdyb3RlOgo+ID4gPj4+Cj4gPiA+Pj4+IE9u IDExLzcvMTggMTA6MjMgQU0sIEFsYW4gU3Rlcm4gd3JvdGU6Cj4gPiA+Pj4+PiBPbiBUdWUsIDYg Tm92IDIwMTgsIEZsb3JpYW4gRmFpbmVsbGkgd3JvdGU6Cj4gPiA+Pj4+Pgo+ID4gPj4+Pj4+IE9u IDExLzYvMTggMTo0MCBQTSwgQWwgQ29vcGVyIHdyb3RlOgo+ID4gPj4+Pj4+PiBPbiAxMS82LzE4 IDExOjA4IEFNLCBBbGFuIFN0ZXJuIHdyb3RlOgo+ID4gPj4+Pj4+Pj4gT24gTW9uLCA1IE5vdiAy MDE4LCBBbCBDb29wZXIgd3JvdGU6Cj4gPiA+Pj4+Pj4+Pgo+ID4gPj4+Pj4+Pj4+IEFkZCBzdXBw b3J0IGZvciBCcm9hZGNvbSBTVEIgU29DJ3MgdG8gdGhlIG9oY2kgcGxhdGZvcm0gZHJpdmVyLgo+ ID4gPj4+Pj4+Pj4+Cj4gPiA+Pj4+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogQWwgQ29vcGVyIDxhbGNv b3BlcnhAZ21haWwuY29tPgo+ID4gPj4+Pj4+Pj4+IC0tLQo+ID4gPj4+Pj4+Pj4KPiA+ID4+Pj4+ Pj4+PiBAQCAtMTc3LDYgKzE4OSw4IEBAIHN0YXRpYyBpbnQgb2hjaV9wbGF0Zm9ybV9wcm9iZShz dHJ1Y3QKPiA+ID4+Pj4+Pj4+PiBwbGF0Zm9ybV9kZXZpY2UgKmRldikKPiA+ID4+Pj4+Pj4+PiAg ICAgICAgICAgICBvaGNpLT5mbGFncyB8PSBPSENJX1FVSVJLX0ZSQU1FX05POwo+ID4gPj4+Pj4+ Pj4+ICAgICAgICAgaWYgKHBkYXRhLT5udW1fcG9ydHMpCj4gPiA+Pj4+Pj4+Pj4gICAgICAgICAg ICAgb2hjaS0+bnVtX3BvcnRzID0gcGRhdGEtPm51bV9wb3J0czsKPiA+ID4+Pj4+Pj4+PiArICAg IGlmIChwZGF0YS0+c3VzcGVuZF93aXRob3V0X3BoeV9leGl0KQo+ID4gPj4+Pj4+Pj4+ICsgICAg ICAgIGhjZC0+c3VzcGVuZF93aXRob3V0X3BoeV9leGl0ID0gMTsKPiA+ID4+Pj4+Pj4+Cj4gPiA+ Pj4+Pj4+PiBTb3JyeSBpZiBJIG1pc3NlZCB0aGlzIGluIHRoZSBlYXJsaWVyIGRpc2N1c3Npb25z Li4uICBJcyB0aGVyZSBhbnkKPiA+ID4+Pj4+Pj4+IHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhIERU IGJpbmRpbmcgdGhhdCBjb3VsZCBleHByZXNzIHRoaXMKPiA+ID4+Pj4+Pj4+IHJlcXVpcmVtZW50 LAo+ID4gPj4+Pj4+Pj4gaW5zdGVhZCBvZiBwdXR0aW5nIGl0IGluIHRoZSBwbGF0Zm9ybSBkYXRh Pwo+ID4gPj4+Pj4+Pj4KPiA+ID4+Pj4+Pj4+IEFsYW4gU3Rlcm4KPiA+ID4+Pj4+Pj4+Cj4gPiA+ Pj4+Pj4+Cj4gPiA+Pj4+Pj4+IEFsYW4sCj4gPiA+Pj4+Pj4+Cj4gPiA+Pj4+Pj4+IFRoYXQgd2Fz IG15IG9yaWdpbmFsIGFwcHJvYWNoIGJ1dCBpbnRlcm5hbCByZXZpZXcgc3VnZ2VzdGVkIHRoYXQK PiA+ID4+Pj4+Pj4gSSB1c2UKPiA+ID4+Pj4+Pj4gcGRhdGEgaW5zdGVhZC4gQmVsb3cgaXMgbXkg b3JpZ2luYWwgcGF0Y2ggZm9yOgo+ID4gPj4+Pj4+Cj4gPiA+Pj4+Pj4gQW5kIHRoZSByZWFzb24g Zm9yIHRoYXQgc3VnZ2VzdGlvbiB3YXMgcmVhbGx5IGJlY2F1c2UgaXQgd2FzCj4gPiA+Pj4+Pj4g cGVyY2V2aWVkCj4gPiA+Pj4+Pj4gYXMgZW5jb2RpbmcgYSBkcml2ZXIgYmVoYXZpb3IgYXMgYSBE ZXZpY2UgVHJlZSBwcm9wZXJ0eSBhcyBvcHBvc2VkIHRvCj4gPiA+Pj4+Pj4gZGVzY3JpYmluZyBz b21ldGhpbmcgdGhhdCB3YXMgaW5oZXJlbnRseSBhbmQgc3RyaWN0bHkgYSBoYXJkd2FyZQo+ID4g Pj4+Pj4+IGJlaGF2aW9yICh0aGVyZWZvcmUgc3VpdGFibGUgZm9yIERldmljZSBUcmVlKS4KPiA+ ID4+Pj4+Cj4gPiA+Pj4+PiBSaWdodC4gIFRoZSBiZXN0IHdheSB0byBhcHByb2FjaCB0aGlzIHBy b2JsZW0gaXMgdG8gaWRlbnRpZnkgYW5kCj4gPiA+Pj4+PiBjaGFyYWN0ZXJpemUgdGhlIGhhcmR3 YXJlIGJlaGF2aW9yIHdoaWNoIG1ha2VzIHRoaXMgb3ZlcnJpZGUKPiA+ID4+Pj4+IG5lY2Vzc2Fy eS4KPiA+ID4+Pj4+IFRoZW4gX3RoYXRfIGNhbiBiZSBhZGRlZCB0byBEVCwgc2luY2UgaXQgd2ls bCBiZSBhIHByb3BlcnR5IG9mIHRoZQo+ID4gPj4+Pj4gaGFyZHdhcmUgcmF0aGVyIHRoYW4gb2Yg dGhlIGRyaXZlci4KPiA+ID4+Pj4+Cj4gPiA+Pj4+Pj4+IEFkZCB0aGUgYWJpbGl0eSB0byBza2lw IGNhbGxpbmcgdGhlIFBIWSdzIGV4aXQgcm91dGluZSBvbiBzdXNwZW5kCj4gPiA+Pj4+Pj4+IGFu ZCB0aGUgUEhZJ3MgaW5pdCByb3V0aW5lIG9uIHJlc3VtZS4gVGhpcyBpcyB0byBoYW5kbGUgYSBV U0IgUEhZCj4gPiA+Pj4+Pj4+IHRoYXQgc2hvdWxkIGhhdmUgaXQncyBwb3dlcl9vZmYgZnVuY3Rp b24gY2FsbGVkIG9uIHN1c3BlbmQgYnV0Cj4gPiA+Pj4+Pj4+IGNhbm5vdAo+ID4gPj4+Pj4+PiBo YXZlIGl0J3MgZXhpdCBmdW5jdGlvbiBjYWxsZWQgYmVjYXVzZSBvbiBleGl0IGl0IHdpbGwgZGlz YWJsZSB0aGUKPiA+ID4+Pj4+Pj4gUEhZIHRvIHRoZSBwb2ludCB3aGVyZSByZWdpc3RlciBhY2Nl c3NlcyB0byB0aGUgSG9zdCBDb250cm9sbGVycwo+ID4gPj4+Pj4+PiB1c2luZyB0aGUgUEhZIHdp bGwgYmUgZGlzYWJsZWQgYW5kIHRoZSBob3N0IGRyaXZlcnMgd2lsbCBjcmFzaC4KPiA+ID4+Pj4+ Cj4gPiA+Pj4+PiBXaGF0J3Mgc3BlY2lhbCBhYm91dCB0aGlzIFBIWT8gIFdoeSBkb2VzIHRoZSBl eGl0IGZ1bmN0aW9uIG1lc3MgdGhlCj4gPiA+Pj4+PiBQSFkKPiA+ID4+Pj4+IHVwPyAgT3IgdG8g cHV0IGl0IGFub3RoZXIgd2F5LCB3aHkgZG9lc24ndCB0aGUgZXhpdCBmdW5jdGlvbiBtZXNzIHVw Cj4gPiA+Pj4+PiBvdGhlciBQSFlzIGluIHRoZSBzYW1lIHdheT8KPiA+ID4+Pj4+Cj4gPiA+Pj4+ PiBGb3IgdGhhdCBtYXR0ZXIsIGNhbiB3ZSBjaGFuZ2UgdGhlIGNvZGUgc28gdGhhdCBzdXNwZW5k IGRvZXNuJ3QgY2FsbAo+ID4gPj4+Pj4gdGhlIGV4aXQgZnVuY3Rpb24gZm9yIF9hbnlfIFBIWT8g IFdpbGwganVzdCBjYWxsaW5nIHRoZSBwb3dlcl9vZmYKPiA+ID4+Pj4+IGZ1bmN0aW9uIGJlIGdv b2QgZW5vdWdoPyAgSWYgbm90LCB0aGVuIHdoeSBub3Q/Cj4gPiA+Pj4+Pgo+ID4gPj4+Pj4gQWxh biBTdGVybgo+ID4gPj4+Pj4KPiA+ID4+Pj4KPiA+ID4+Pj4gSW4gb3VyIFVTQiBoYXJkd2FyZSB0 aGUgVVNCIFBIWSBzdXBwbGllcyBhIGNsb2NrIGZvciB0aGUgRUhDSS9PSENJIGFuZAo+ID4gPj4+ PiBYSENJIGhvc3QgY29udHJvbGxlcnMgYW5kIGlmIHRoZSBQSFkgaXMgdG90YWxseSBzaHV0IGRv d24gdGhlIEVIQ0ksCj4gPiA+Pj4+IE9IQ0kKPiA+ID4+Pj4gYW5kIFhIQ0kgcmVnaXN0ZXJzIHdp bGwgY2F1c2UgYW4gZXhjZXB0aW9uIGlmIGFjY2Vzc2VkIGFuZCBjYXVzZSB0aGUKPiA+ID4+Pj4g RUhDSSwgT0hDSSBhbmQgWEhDSSBkcml2ZXJzIHRvIGNyYXNoLiBUaGVyZSBpcyBhbHdheXMgdGFs ayBvZiBmaXhpbmcKPiA+ID4+Pj4gdGhpcyBpbiB0aGUgaGFyZHdhcmUgYnkgYWRkaW5nIGFuIGF1 eCBjbG9jayB0aGF0IHdpbGwgdGFrZW92ZXIgd2hlbiB0aGUKPiA+ID4+Pj4gUEhZIGNsb2NrIGlz IHNodXQgZG93biwgYnV0IHRoaXMgaGFzbid0IGhhcHBlbmVkIHlldC4gSXQgc2VlbXMgbGlrZQo+ ID4gPj4+PiAiZXhpdCBvbiBzdXNwZW5kIiBzdGlsbCBtYWtlcyBzZW5zZSBvbiBzeXN0ZW1zIHRo YXQgZG9uJ3QgaGF2ZSB0aGlzCj4gPiA+Pj4+IHByb2JsZW0gKGFkZGl0aW9uYWwgcG93ZXIgc2F2 aW5ncz8pIHNvIHJlbW92aW5nIHRoZSBleGl0IG9uIHN1c3BlbmQgZm9yCj4gPiA+Pj4+IGFsbCBz eXN0ZW1zIGlzIG5vdCBhIGdvb2QgaWRlYS4KPiA+ID4+Pgo+ID4gPj4+IFRoZW4gaW4gdGhlb3J5 IHlvdSBzaG91bGQgYmUgYWJsZSB0byBhZGQgYSBEZXZpY2UgVHJlZSBwcm9wZXJ0eSB3aGljaAo+ ID4gPj4+IHNheXMgdGhhdCB0aGUgUEhZIHByb3ZpZGVzIGEgY2xvY2sgZm9yIHRoZSBVU0IgaG9z dCBjb250cm9sbGVyLiAgVGhhdAo+ID4gPj4+IGlzIHN0cmljdGx5IGEgcHJvcGVydHkgb2YgdGhl IGhhcmR3YXJlOyBpdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZQo+ID4gPj4+IGRyaXZlci4g IFRoZXJlZm9yZSBpdCBpcyBhcHByb3ByaWF0ZSBmb3IgRFQuCj4gPiA+Pgo+ID4gPj4gVGhlIHZl cnkgY29tcGF0aWJsZSBzdHJpbmcgdGhhdCBpcyBiZWluZyBhbGxvY2F0ZWQvZGVmaW5lZCBmb3Ig dGhpcwo+ID4gPj4gY29udHJvbGxlciBjYXJyaWVzIHRoYXQgaW5mb3JtYXRpb24gYWxyZWFkeSwg dGhhdCBpcywgaWYgeW91IHByb2JlIGEKPiA+ID4+ICJicmNtLGJjbTc0NDUtb2hjaSIgY29tcGF0 aWJsZSB0aGVuIHRoYXQgbWVhbnMgdGhlIGNvbnRyb2xsZXIgaGFzIGEKPiA+ID4+IGRlcGVuZGVu Y3kgb24gdGhlIFBIWSB0byBzdXBwbHkgaXRzIGNsb2NrLgo+ID4gPj4KPiA+ID4+IEFkZGluZyBh IHByb3BlcnR5IHZzLiBrZXlpbmcgb24gdGhlIGNvbXBhdGlibGUgc3RyaW5nIG1ha2VzIHNlbnNl IGlmIHlvdQo+ID4gPj4ga25vdyB0aGVyZSBpcyBhdCBsZWFzdCBhIHNlY29uZCBjb25zdW1lciBv ZiB0aGF0IHByb3BlcnR5ICh1bmxlc3Mgd2UKPiA+ID4+IG1ha2UgaXQgYSBicm9hZGNvbSBzcGVj aWZpYyBwcm9wZXJ0eSwgaW4gd2hpY2ggY2FzZSwgaXQgcmVhbGx5IGlzCj4gPiA+PiByZWR1bmRh bnQgd2l0aCB0aGUgY29tcGF0aWJsZSBzdHJpbmcpLgo+ID4gPj4KPiA+ID4+IEFueXdheSwgbXkg Z3J1ZGdlIHdpdGggdGhhdCBwcm9wZXJ0eSB3YXMgdGhlIG5hbWUgY2hvc2VuIGluaXRpYWxseSwK PiA+ID4+IHdoaWNoIGluY2x1ZGVkIGFuIGFjdGlvbiB0byBiZSBwZXJmb3JtZWQgYnkgYW4gaW1w bGVtZW50YXRpb24gYXMgb3Bwb3NlZAo+ID4gPj4gdG8gc29tZXRoaW5nIHB1cmVseSBkZXNjcmlw dGl2ZS4gRS5nOiAncGh5LXN1cHBsaWVzLWNsb2NrJyBtaWdodCBiZSBva2F5Lgo+ID4gPj4KPiA+ ID4+Pgo+ID4gPj4+IFdvdWxkbid0IHRoaXMgc29sdmUgeW91ciBpc3N1ZT8KPiA+ID4+Cj4gPiA+ PiBJdCB3b3VsZCBub3QgY2hhbmdlIG11Y2ggZXhjZXB0IHRoYXQgdGhlcmUgaXMgbm8gbmVlZCB0 byBtdWNoIHdpdGgKPiA+ID4+IG9oY2ktcGxhdGZvcm0uYyBhbnltb3JlLCBidXQgdWx0aW1hdGVs eSB0aGF0IHByb3BlcnR5IG5lZWRzIHRvIGJlIHJlYWQKPiA+ID4+IGJ5IG9oY2ktaGNkLmMgYW5k IGFjdGVkIG9uLCB3aGljaCB3b3VsZCBsaWtlbHkgbGVhZCB0byB0aGUgc2FtZSBhbW91bnQKPiA+ ID4+IG9mIGNoYW5nZXMgYXMgdGhvc2UgcHJlc2VudCBpbiBwYXRjaCAjMiBjdXJyZW50bHkuCj4g PiA+Pgo+ID4gPiBXZSBhbHNvIG5lZWQgdGhpcyBmdW5jdGlvbmFsaXR5IGluIHRoZSBFSENJIGFu ZCBYSENJIGRyaXZlcnMgYW5kIGl0J3MKPiA+ID4gbm90IHRoZSBvaGNpLWhjZC5jIG1vZHVsZSB0 aGF0IG5lZWRzIHRvIGtub3csIGl0J3MgdGhlIGNvcmUvcGh5LmMgbW9kdWxlCj4gPiA+IGNhbGxl ZCBmcm9tIGNvcmUvaGNkLmMuCj4gPgo+ID4gU28gaW4gdGhhdCByZWdhcmQgdGhlIERldmljZSBU cmVlIHByb3BlcnR5IHdvdWxkIGFjdHVhbGx5IHNjYWxlIGEgYml0Cj4gPiBiZXR0ZXIgaW4gdGhh dCB5b3Ugd291bGQgbm8gbG9uZ2VyIG5lZWQgdG8gbW9kaWZ5IHRoZSB2YXJpb3VzCj4gPiAqaGNp LXBsYXQqLmMgZmlsZXMsIGlmIHRoYXQgaXMgdGhlIHdheSB0byBnbywgdGhlbiBzdXJlLgo+Cj4g U291bmRzIGxpa2UgdGhlIHBoeSBuZWVkcyB0byBiZSBhIGNsb2NrIHByb3ZpZGVyIHRvIHRoZSBV U0IgY29udHJvbGxlci4KPiBNYXliZSB0aGF0J3MgYSBiaXQgb2Ygb3ZlcmtpbGwsIGJ1dCB3b3Vs ZCBiZSB0aGUgbW9zdCBhY2N1cmF0ZS4KPgo+IE90aGVyd2lzZSwgbXkgcHJlZmVyZW5jZSBpcyB1 c2luZyB0aGUgY29tcGF0aWJsZSBzdHJpbmcuIElPVywgd2UgYWxyZWFkeQo+IGhhdmUgcHJvcGVy dGllcyB0byBoYW5kbGUgdGhpcy4gSWYgeW91IGRvbid0IHdhbnQgdG8gdXNlIHRoZW0sIHRoZW4g dXNlCj4gY29tcGF0aWJsZSByYXRoZXIgdGhhbiBpbnZlbnRpbmcgc29tZXRoaW5nIG5ldyBhbmQg Y3VzdG9tLgoKTXkgcHJldmlvdXMgY29tbWl0IHVzZWQgdGhlIGNvbXBhdGlibGUgc3RyaW5nIHRv IHNldCB0aGUgSENEIGZsYWcKaW5zdGVhZCBvZiBhIGRldmljZSB0cmVlIHByb3BlcnR5LCBidXQg QWxhbiBTdGVybiBhc2sgbWUgdG8gdXNlIGEgRFQKYmluZGluZyBpbnN0ZWFkLiBUaGlzIGhhcyB0 aGUgYWR2YW50YWdlIG9mIGhhdmluZyB0aGUgY29kZSBpbiBvbmUKcGxhY2UgaW4gdGhlIHBoeS5j IG1vZHVsZSBpbnN0ZWFkIG9mIGhhdmluZyB0byBhZGQgaXQgdG8gdGhlIE9IQ0ksCkVIQ0kgYW5k IFhIQ0kgcGxhdGZvcm0gZHJpdmVycy4KCj4KPiBBdCBsZWFzdCBsYXN0IHRpbWUgSSBsb29rZWQs IHRoZXJlJ3MgYSBsYWNrIG9mIHN1cHBvcnQgaW4gdGhlIFBIWSBBUEkgdG8KPiBoYW5kbGUgdmFy aW91cyBoYW5kc2hha2VzIG5lZWRlZCBiZXR3ZWVuIHBoeXMgYW5kIGNvbnRyb2xsZXJzIGxpa2Ug dGhpcy4KPiBJdCdzIGZhaXJseSBlYXN5IGZvciB0aGUgY29udHJvbGxlciB0byBmZXRjaCBpbmZv IGZyb20gYSBwaHkgbm9kZSwgYnV0Cj4gdGhlIG9wcG9zaXRlIGlzIG5vdCBzbyBlYXN5LiBJdCBz ZWVtcyB0byBtZSBzb21lIEFQSSBmb3IgY29udHJvbGxlcnMgdG8KPiBzZXQgZmxhZ3MgaW4gdGhl IHBoeSBkcml2ZXIgaXMgbmVlZGVkLgoKVGhlIEdlbmVyaWMgUEhZIHN1YnN5c3RlbSBhbGxvd3Mg dGhlIFBIWSBwcm92aWRlciB0byBleHBvcnQKcGh5X3Bvd2VyX29uL3BoeV9wb3dlcl9vZmYgYW5k IHBoeV9pbml0L3BoeV9leGl0IGZ1bmN0aW9ucyBmb3IgdXNlIGJ5CnRoZSBQSFkgY29uc3VtZXIu IFRoZSBleGFjdCBmdW5jdGlvbmFsaXR5IG9mIHRoZXNlIHJvdXRpbmVzIHNlZW1zIHRvCnZhcnkg YW1vbmcgdGhlIGRpZmZlcmVudCBQSFkgcHJvdmlkZXIgZHJpdmVycy4gVGhlIEJyb2FkY29tIFVT QiBQSFkKZHJpdmVyIGV4cGVjdHMgdGhlIHBoeV9wb3dlcl9vbi9waHlfcG93ZXJfb2ZmIHRvIGJl IHVzZWQgb24Kc3VzcGVuZC9yZXN1bWUgYW5kIHRoZSBwaHlfaW5pdC9waHlfZXhpdCB0byBiZSB1 c2VkIGJ5IHRoZSBjb25zdW1lcgpkcml2ZXIncyBwcm9iZS9yZW1vdmUgcm91dGluZXMuIFRoZSBu ZXcgVVNCIFBIWSBjb25zdW1lciBjb2RlIGRvZXMgbm90CmRvIHRoaXMsIGluc3RlYWQgaXQgY2Fs bHMgYm90aCBwb3dlcl9vZmYgQU5EIGV4aXQgZm9yIGJvdGggc3VzcGVuZAoobm90IHdha2FibGUp IGFuZCByZW1vdmUuIElmIHlvdSBsb29rIGF0IG90aGVyIFBIWSBwcm92aWRlci9jb25zdW1lcgpp bXBsZW1lbnRhdGlvbnMgaW4gdGhlIGtlcm5lbCB0cmVlIHlvdSdsbCBmaW5kIGV4YW1wbGVzIG9m IGJvdGggdGhlc2UKbWV0aG9kcyBidXQgdGhlcmUgYXJlIG1vcmUgZXhhbXBsZXMgdGhhdCBiZWhh dmUgbGlrZSB0aGUgQnJvYWRjb20gUEhZLgpXaGF0IEkgd2FzIHRyeWluZyB0byBkbyB3YXMgdG8g dXNlIGEgRFQgcHJvcGVydHkgdG8gdGVsbCB0aGUgVVNCIFBIWQpjb25zdW1lciBjb2RlIHdoaWNo IG1ldGhvZCB0byB1c2UuCgpJIGd1ZXNzIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGN1cnJlbnQg Z2VuZXJpYyBQSFkgYXBpIG9ubHkgYWxsb3dzCnRoZSBjb25zdW1lciB0byBwdXQgdGhlIFBIWSBp biAxIG9mIDMgc3RhdGVzLCBFWElULCBPRkYgb3IgT04uIFRoZQpjdXJyZW50IFVTQiBQSFkgY29u c3VtZXIgY29kZSBpcyB1c2luZyBPRkYgZm9yICJzdXNwZW5kIHdpdGggd2FrZXVwIgphbmQgRVhJ VCBmb3IgInN1c3BlbmQgd2l0aG91dCB3YWtldXAiLiBUaGUgQnJvYWRjb20gUEhZIGRyaXZlciB3 YW50cwpPRkYgZm9yIGVpdGhlciAic3VzcGVuZCB3aXRoIHdha2V1cCIgb3IgInN1c3BlbmQgd2l0 aG91dCB3YWtldXAiIGFuZApFWElUIHdoZW4gdGhlcmUgYXJlIG5vIGNvbnN1bWVycyB1c2luZyB0 aGUgUEhZLiBJZiB0aGUgUEhZIEFQSSBhbGxvd2VkCmZvciA0IHN0YXRlcywgRVhJVCwgT0ZGX05P VF9XQUtBQkxFLCBPRkZfV0FLQUJMRSBhbmQgT04gdGhlbiB0aGUKaW5kaXZpZHVhbCBQSFkgcHJv dmlkZXIgY291bGQgaGlkZSB0aGUgZGlmZmVyZW5jZXMsIGJ1dCB0aGlzIHNlZW1zCmhhcmQgdG8g cmV0cm9maXQgaW50byB0aGUgUEhZIHN1YnN5c3RlbS4KCkFsCgo+Cj4gUm9iCj4K