Re: [Emc-users] 3D Printed L Type Timing Pulleys

[Sven Wesley]

Den lör 2 jan. 2021 kl 20:27 skrev John Dammeyer :

> > From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> > I've seen CAD models of the complete Bridgeport machine on GrabCad.   It
> > really is helpful to have a good model so you can test-fit parts before
> you
> > make them.
> >
> > I found a model of my Harbor Fright minimill so now I can able to make
> > add-on parts that match the screw-holes on the mill, first try.   Yes I
> had
> > the verify the model.   I would not trust something I downloaded.
> >
> > I know what you said about dropping the z-axis faster than gravity
> allows.
> >   I'm using a ball screw for that.  Turns out the Chinese ball screws are
> > cheap and actually better than spec'd.
> >
> Mine is equivalent to a Grizzly Tools G3616 now no longer made.  And in
> Canada House of Tools is long gone.  The first thing I need to do is swap
> the XY with ball screws.  There's a guy in Australia that did a major
> rework on this machine so he has some good videos and ideas.
>
> Needless to say there is no 3D rendering of the entire machine.  I started
> on that about 8 years ago when I first got AlibreCAD.  Now I might move
> forward with that and do some more.
>
> The knee assembly is just the screw and pulleys.  The Y axis has a
> truncated Knee casting since a full one would get in the way of seeing
> things, even with transparency.   And I only did enough of the X axis to
> make sure things looked right.
>
> Haven't yet figured out how to create an assembly that has a toothed belt
> that can be animated.  I'm sure it's possible.  But is it really worth the
> time...
>
> I've also modeled several different ways to do ball screws.  The X axis
> has over 0.012" of backlash.  Aggressive climb milling will pull the
> table.  So ball screws are next on the list once I bundle up rest of the
> control cabinet.
>
> I now have enough AC Servos for the other axis but for now that would be
> repeating what already works.  X and Y are DC brushed servos driven with
> HP_UHU kits. (I have two spares of those too).
>
> And  pump oiler that still needs to be installed and plumbed.
>
> John
>

I made HTD5 pulleys two years something ago. We made an automation machine
that needed bigger pulleys that we could find so I 3D printed one, sanded
it slightly to smooth the grooves, made a silicone mould from it and then
made two copies in GF powder reinforced epoxy. They are rock solid and the
machins runs on a daily basis.

/Sven

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[PATCH] PCI:tegra:Correct typo for PCIe endpoint mode in Tegra194

[Wesley Sheng]

In config PCIE_TEGRA194_EP the mode incorrectly referred to
host mode.

Signed-off-by: Wesley Sheng 
---
 drivers/pci/controller/dwc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 044a3761c44f..6960babe6161 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -273,7 +273,7 @@ config PCIE_TEGRA194_EP
select PCIE_TEGRA194
help
  Enables support for the PCIe controller in the NVIDIA Tegra194 SoC to
- work in host mode. There are two instances of PCIe controllers in
+ work in endpoint mode. There are two instances of PCIe controllers in
  Tegra194. This controller can work either as EP or RC. In order to
  enable host-specific features PCIE_TEGRA194_HOST must be selected and
  in order to enable device-specific features PCIE_TEGRA194_EP must be
-- 
2.16.2

[PATCH v2 0/2] Allow DWC3 runtime suspend if UDC is unbinded

[Wesley Cheng]

Changes in v2:
 - Modified logic for executing the runtime PM resume.  Using a sychronous get
   call to avoid race conditions.

During the following scenario, the DWC3 runtime suspend routine is blocked as
the connected flag is still true:

1.  Enumerate device w/ host.
2.  Gadget is unbinded
- echo "" > /sys/kernel/config/usb_gadget/g1/UDC
3.  Disconnect the USB cable (VBUS low)
4.  No dwc3_gadget_disconnect_interrupt() seen (since controller is
   halted from step#1)
5.  Runtime PM autosuspend fails due to "dwc->connected" being true
(cleared in dwc3_gadget_disconnect_interrupt())
6.  Gadget binded
- echo udc_name > /sys/kernel/config/usb_gadget/g1/UDC
7.  No runtime suspend until cable is plugged in and out

Technically, for device initiated disconnects, there is no active session/link
with the host, so the DWC3 controller should be allowed to go into a low power
state.  Also, we need to now consider when re-binding the UDC,
dwc3_gadget_set_speed() is executed before dwc3_gadget_pullup(), so if the DWC3
controller is suspended/disabled, while accessing the DCFG, that could result in
bus timeouts, etc...  Change the dwc3_gadget_set_speed() to save the speed
being requested, and program it during dwc3_gadget_run_stop(), which is executed
during PM runtime resume.  If not, previous setting will be overridden as we
execute a DWC3 controller reset during PM runtime resume. 

Wesley Cheng (2):
  usb: dwc3: gadget: Allow runtime suspend if UDC unbinded
  usb: dwc3: gadget: Preserve UDC max speed setting

 drivers/usb/dwc3/core.h   |   1 +
 drivers/usb/dwc3/gadget.c | 121 ++
 2 files changed, 71 insertions(+), 51 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/2] usb: dwc3: gadget: Preserve UDC max speed setting

[Wesley Cheng]

The USB gadget/UDC driver can restrict the DWC3 controller speed using
dwc3_gadget_set_speed().  Store this setting into a variable, in order for
this setting to persist across controller resets due to runtime PM.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/core.h   |   1 +
 drivers/usb/dwc3/gadget.c | 108 --
 2 files changed, 58 insertions(+), 51 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 2f04b3e42bf1..390d3deef0ba 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1119,6 +1119,7 @@ struct dwc3 {
u32 nr_scratch;
u32 u1u2;
u32 maximum_speed;
+   u32 gadget_max_speed;
 
u32 ip;
 
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index babf977cadc0..c145da1d8ba5 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1941,6 +1941,61 @@ static void dwc3_stop_active_transfers(struct dwc3 *dwc)
}
 }
 
+static void __dwc3_gadget_set_speed(struct dwc3 *dwc)
+{
+   u32 reg;
+
+   reg = dwc3_readl(dwc->regs, DWC3_DCFG);
+   reg &= ~(DWC3_DCFG_SPEED_MASK);
+
+   /*
+* WORKAROUND: DWC3 revision < 2.20a have an issue
+* which would cause metastability state on Run/Stop
+* bit if we try to force the IP to USB2-only mode.
+*
+* Because of that, we cannot configure the IP to any
+* speed other than the SuperSpeed
+*
+* Refers to:
+*
+* STAR#9000525659: Clock Domain Crossing on DCTL in
+* USB 2.0 Mode
+*/
+   if (DWC3_VER_IS_PRIOR(DWC3, 220A) &&
+   !dwc->dis_metastability_quirk) {
+   reg |= DWC3_DCFG_SUPERSPEED;
+   } else {
+   switch (dwc->gadget_max_speed) {
+   case USB_SPEED_LOW:
+   reg |= DWC3_DCFG_LOWSPEED;
+   break;
+   case USB_SPEED_FULL:
+   reg |= DWC3_DCFG_FULLSPEED;
+   break;
+   case USB_SPEED_HIGH:
+   reg |= DWC3_DCFG_HIGHSPEED;
+   break;
+   case USB_SPEED_SUPER:
+   reg |= DWC3_DCFG_SUPERSPEED;
+   break;
+   case USB_SPEED_SUPER_PLUS:
+   if (DWC3_IP_IS(DWC3))
+   reg |= DWC3_DCFG_SUPERSPEED;
+   else
+   reg |= DWC3_DCFG_SUPERSPEED_PLUS;
+   break;
+   default:
+   dev_err(dwc->dev, "invalid speed (%d)\n", 
dwc->gadget_max_speed);
+
+   if (DWC3_IP_IS(DWC3))
+   reg |= DWC3_DCFG_SUPERSPEED;
+   else
+   reg |= DWC3_DCFG_SUPERSPEED_PLUS;
+   }
+   }
+   dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+}
+
 static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
 {
u32 reg;
@@ -1963,6 +2018,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int 
is_on, int suspend)
if (dwc->has_hibernation)
reg |= DWC3_DCTL_KEEP_CONNECT;
 
+   __dwc3_gadget_set_speed(dwc);
dwc->pullups_connected = true;
} else {
reg &= ~DWC3_DCTL_RUN_STOP;
@@ -2325,59 +2381,9 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
 {
struct dwc3 *dwc = gadget_to_dwc(g);
unsigned long   flags;
-   u32 reg;
 
spin_lock_irqsave(>lock, flags);
-   reg = dwc3_readl(dwc->regs, DWC3_DCFG);
-   reg &= ~(DWC3_DCFG_SPEED_MASK);
-
-   /*
-* WORKAROUND: DWC3 revision < 2.20a have an issue
-* which would cause metastability state on Run/Stop
-* bit if we try to force the IP to USB2-only mode.
-*
-* Because of that, we cannot configure the IP to any
-* speed other than the SuperSpeed
-*
-* Refers to:
-*
-* STAR#9000525659: Clock Domain Crossing on DCTL in
-* USB 2.0 Mode
-*/
-   if (DWC3_VER_IS_PRIOR(DWC3, 220A) &&
-   !dwc->dis_metastability_quirk) {
-   reg |= DWC3_DCFG_SUPERSPEED;
-   } else {
-   switch (speed) {
-   case USB_SPEED_LOW:
-   reg |= DWC3_DCFG_LOWSPEED;
-   break;
-   case USB_SPEED_FULL:
-   reg |= DWC3_DCFG_FULLSPEED;
-   break;
-   case USB_SPEED_HIGH:
-   reg |= DWC3_DCFG_HIGHSPEED;
-   break;
-   

[PATCH 3/3] usb: gadget: configfs: Add a specific configFS reset callback

[Wesley Cheng]

In order for configFS based USB gadgets to set the proper charge current
for bus reset scenarios, expose a separate reset callback to set the
current to 100mA based on the USB battery charging specification.

Reviewed-by: Peter Chen 
Signed-off-by: Wesley Cheng 
---
 drivers/usb/gadget/configfs.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 56051bb97349..80ca7ff2fb97 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1481,6 +1481,28 @@ static void configfs_composite_disconnect(struct 
usb_gadget *gadget)
spin_unlock_irqrestore(>spinlock, flags);
 }
 
+static void configfs_composite_reset(struct usb_gadget *gadget)
+{
+   struct usb_composite_dev *cdev;
+   struct gadget_info *gi;
+   unsigned long flags;
+
+   cdev = get_gadget_data(gadget);
+   if (!cdev)
+   return;
+
+   gi = container_of(cdev, struct gadget_info, cdev);
+   spin_lock_irqsave(>spinlock, flags);
+   cdev = get_gadget_data(gadget);
+   if (!cdev || gi->unbind) {
+   spin_unlock_irqrestore(>spinlock, flags);
+   return;
+   }
+
+   composite_reset(gadget);
+   spin_unlock_irqrestore(>spinlock, flags);
+}
+
 static void configfs_composite_suspend(struct usb_gadget *gadget)
 {
struct usb_composite_dev *cdev;
@@ -1530,7 +1552,7 @@ static const struct usb_gadget_driver 
configfs_driver_template = {
.unbind = configfs_composite_unbind,
 
.setup  = configfs_composite_setup,
-   .reset  = configfs_composite_disconnect,
+   .reset  = configfs_composite_reset,
.disconnect = configfs_composite_disconnect,
 
.suspend= configfs_composite_suspend,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/2] usb: dwc3: gadget: Allow runtime suspend if UDC unbinded

[Wesley Cheng]

The DWC3 runtime suspend routine checks for the USB connected parameter to
determine if the controller can enter into a low power state.  The
connected state is only set to false after receiving a disconnect event.
However, in the case of a device initiated disconnect (i.e. UDC unbind),
the controller is halted and a disconnect event is never generated.  Set
the connected flag to false if issuing a device initiated disconnect to
allow the controller to be suspended.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/gadget.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 5d879b7606d5..babf977cadc0 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2012,6 +2012,17 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
}
}
 
+   /*
+* Check the return value for successful resume, or error.  For a
+* successful resume, the DWC3 runtime PM resume routine will handle
+* the run stop sequence, so avoid duplicate operations here.
+*/
+   ret = pm_runtime_get_sync(dwc->dev);
+   if (!ret || ret < 0) {
+   pm_runtime_put(dwc->dev);
+   return 0;
+   }
+
/*
 * Synchronize any pending event handling before executing the 
controller
 * halt routine.
@@ -2050,10 +2061,12 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
dwc->ev_buf->lpos = (dwc->ev_buf->lpos + count) %
dwc->ev_buf->length;
}
+   dwc->connected = false;
}
 
ret = dwc3_gadget_run_stop(dwc, is_on, false);
spin_unlock_irqrestore(>lock, flags);
+   pm_runtime_put(dwc->dev);
 
return ret;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/3] usb: dwc3: gadget: Introduce a DWC3 VBUS draw callback

[Wesley Cheng]

Some devices support charging while in device mode.  In these situations,
the USB gadget will notify the DWC3 gadget driver to modify the current
based on the enumeration and device state.  The usb_phy_set_power() API
will allow external charger entities to adjust the charge current through
the notifier block.

Reviewed-by: Peter Chen 
Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/gadget.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c145da1d8ba5..69122f66978e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2387,6 +2387,16 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
spin_unlock_irqrestore(>lock, flags);
 }
 
+static int dwc3_gadget_vbus_draw(struct usb_gadget *g, unsigned int mA)
+{
+   struct dwc3 *dwc = gadget_to_dwc(g);
+
+   if (dwc->usb2_phy)
+   return usb_phy_set_power(dwc->usb2_phy, mA);
+
+   return 0;
+}
+
 static const struct usb_gadget_ops dwc3_gadget_ops = {
.get_frame  = dwc3_gadget_get_frame,
.wakeup = dwc3_gadget_wakeup,
@@ -2396,6 +2406,7 @@ static const struct usb_gadget_ops dwc3_gadget_ops = {
.udc_stop   = dwc3_gadget_stop,
.udc_set_speed  = dwc3_gadget_set_speed,
.get_config_params  = dwc3_gadget_config_params,
+   .vbus_draw  = dwc3_gadget_vbus_draw,
 };
 
 /* -- 
*/
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/3] usb: gadget: composite: Split composite reset and disconnect

[Wesley Cheng]

Add a specific composite reset API to differentiate between disconnect and
reset events.  This is needed for adjusting the current draw accordingly
based on the USB battery charging specification.  The device is only allowed
to draw the 500/900 mA (HS/SS) while in the CONFIGURED state, and only 100 mA
in the connected and UNCONFIGURED state.

Reviewed-by: Peter Chen 
Signed-off-by: Wesley Cheng 
---
 drivers/usb/gadget/composite.c | 21 +++--
 include/linux/usb/composite.h  |  2 ++
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 05b176c82cc5..a41f7fe4b518 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -2036,7 +2036,7 @@ composite_setup(struct usb_gadget *gadget, const struct 
usb_ctrlrequest *ctrl)
return value;
 }
 
-void composite_disconnect(struct usb_gadget *gadget)
+static void __composite_disconnect(struct usb_gadget *gadget)
 {
struct usb_composite_dev*cdev = get_gadget_data(gadget);
unsigned long   flags;
@@ -2053,6 +2053,23 @@ void composite_disconnect(struct usb_gadget *gadget)
spin_unlock_irqrestore(>lock, flags);
 }
 
+void composite_disconnect(struct usb_gadget *gadget)
+{
+   usb_gadget_vbus_draw(gadget, 0);
+   __composite_disconnect(gadget);
+}
+
+void composite_reset(struct usb_gadget *gadget)
+{
+   /*
+* Section 1.4.13 Standard Downstream Port of the USB battery charging
+* specification v1.2 states that a device connected on a SDP shall only
+* draw at max 100mA while in a connected, but unconfigured state.
+*/
+   usb_gadget_vbus_draw(gadget, 100);
+   __composite_disconnect(gadget);
+}
+
 /*-*/
 
 static ssize_t suspended_show(struct device *dev, struct device_attribute 
*attr,
@@ -2373,7 +2390,7 @@ static const struct usb_gadget_driver 
composite_driver_template = {
.unbind = composite_unbind,
 
.setup  = composite_setup,
-   .reset  = composite_disconnect,
+   .reset  = composite_reset,
.disconnect = composite_disconnect,
 
.suspend= composite_suspend,
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 2040696d75b6..0d8a71471512 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -525,6 +525,8 @@ extern struct usb_string *usb_gstrings_attach(struct 
usb_composite_dev *cdev,
 extern int usb_string_ids_n(struct usb_composite_dev *c, unsigned n);
 
 extern void composite_disconnect(struct usb_gadget *gadget);
+extern void composite_reset(struct usb_gadget *gadget);
+
 extern int composite_setup(struct usb_gadget *gadget,
const struct usb_ctrlrequest *ctrl);
 extern void composite_suspend(struct usb_gadget *gadget);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/3] Add vbus draw support to DWC3

[Wesley Cheng]

Some devices are connected to standard downstream ports (SDP) and draw current
from them.  The current rates are defined in the BC1.2 specification, and
highlights the different charge rates depending on the device state.  The DWC3
gadget does not currently have a mechanism to notify external drivers about
how much current can be drawn.

The current rates are notified by the USB gadget layer, and the DWC3 gadget will
propagate this potentially to external charger drivers.  Also, the USB gadget
needs to be fixed to only allow 100mA current draw when receiving a bus reset
from the host, as the BC1.2 specification states that this is the max current
draw possible when in the connected and unconfigured state.

Wesley Cheng (3):
  usb: dwc3: gadget: Introduce a DWC3 VBUS draw callback
  usb: gadget: composite: Split composite reset and disconnect
  usb: gadget: configfs: Add a specific configFS reset callback

 drivers/usb/dwc3/gadget.c  | 11 +++
 drivers/usb/gadget/composite.c | 21 +++--
 drivers/usb/gadget/configfs.c  | 24 +++-
 include/linux/usb/composite.h  |  2 ++
 4 files changed, 55 insertions(+), 3 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] usb: dwc3: gadget: Restart DWC3 gadget when enabling pullup

[Wesley Cheng]

usb_gadget_deactivate/usb_gadget_activate does not execute the UDC start
operation, which may leave EP0 disabled and event IRQs disabled when
re-activating the function. Move the enabling/disabling of USB EP0 and
device event IRQs to be performed in the pullup routine.

Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the
controller")

Tested-by: Michael Tretter 
Reported-by: Michael Tretter 
Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/gadget.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 5d879b7606d5..922c8b76e534 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1988,6 +1988,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int 
is_on, int suspend)
 
 static void dwc3_gadget_disable_irq(struct dwc3 *dwc);
 static void __dwc3_gadget_stop(struct dwc3 *dwc);
+static int __dwc3_gadget_start(struct dwc3 *dwc);
 
 static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
 {
@@ -2050,6 +2051,8 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
dwc->ev_buf->lpos = (dwc->ev_buf->lpos + count) %
dwc->ev_buf->length;
}
+   } else {
+   __dwc3_gadget_start(dwc);
}
 
ret = dwc3_gadget_run_stop(dwc, is_on, false);
@@ -2224,10 +2227,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
 
dwc->gadget_driver  = driver;
-
-   if (pm_runtime_active(dwc->dev))
-   __dwc3_gadget_start(dwc);
-
spin_unlock_irqrestore(>lock, flags);
 
return 0;
@@ -2253,13 +2252,6 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
unsigned long   flags;
 
spin_lock_irqsave(>lock, flags);
-
-   if (pm_runtime_suspended(dwc->dev))
-   goto out;
-
-   __dwc3_gadget_stop(dwc);
-
-out:
dwc->gadget_driver  = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RBW] Clem saddle?

[Wesley Applequist]

I've got a Clem saddle I'd be happy to send your way for the cost of 
shipping. 

On Thursday, December 24, 2020 at 5:32:36 PM UTC-6 Eric Daume wrote:

> Wow, I’m surprised anyone wants one of those. That saddle came on the Clem 
> I had, but I only made it a few hundred yards before I turned around to put 
> a different saddle on. It was that immediately painful. 
>
> On Thursday, December 24, 2020, jeffbog...@hotmail.com <
> jeffbog...@hotmail.com> wrote:
>
>>
>> Anyone know what kind of saddle was included in the original Clem 
>> complete? (the grey vinyl one) 
>>
>> I'd like to get one for my sister to put on her new Cheviot. Thanks!
>>
>> Jeff
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "RBW Owners Bunch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/rbw-owners-bunch/0d34c577-b428-403a-a812-ad89308dae03n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/dcf2a3f8-2fdc-475d-9ae7-3def4275bc97n%40googlegroups.com.

Re: Unsubscribe

[Wesley Peng]

Bhavya Jain wrote:

Unsubscribe


please send an email to: user-unsubscr...@spark.apache.org to 
unsubscribe yourself from the list. thanks.


-
To unsubscribe e-mail: user-unsubscr...@spark.apache.org

Re: [Emc-users] 7i96 multi wire input

[Sven Wesley]

Den tors 17 dec. 2020 01:22Gene Heskett  skrev:

> On Wednesday 16 December 2020 17:42:58 Sven Wesley wrote:
>
> > Den tors 10 dec. 2020 kl 15:31 skrev Gene Heskett
> :
> > > But, I'll also state that my way is not the only way, There are
> > > (N-1)! ways to do it where N is the number of inputs you need to
> > > smunch into one wire to stop LCNC, and ! is the factorial symbol.
> > > And could be expanded to handle more fault sources easy enough as
> > > long as they all worked alike. With "work alike" defined as turning
> > > on an isolated switch when it faults.
> > >
> > > Take care Sven.
> > >
> > > Cheers, Gene Heskett
> >
> > Turns out it's all fine to run them all together. Got this drawing
> > from the designer of the driver.
> >
> >
> > [image: error-line.jpg]
>
> That is all fine if you don't care which driver did it, or simply don't
> have enough i/o and you can go inspect the drivers to see which one got
> the tummy ache. I did mine individually because I had the i/o to throw
> away, and still do, probaly 40 unused i/o's yet. And while the drivers
> are accessible, its not all that convenient.  Safety wise, this is 100%
> functional.
>
> Cheers, Gene Heskett
>

All drivers have an LED that flashes when they are throwing an error. Only
the drive that causes an error flashes.
Not too many inputs on the 7i96 so I'm happy if I can save a few. :)

All the best,
Sven

>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] 7i96 multi wire input

[Sven Wesley]

Den tors 10 dec. 2020 kl 15:31 skrev Gene Heskett :

> But, I'll also state that my way is not the only way, There are (N-1)!
> ways to do it where N is the number of inputs you need to smunch into
> one wire to stop LCNC, and ! is the factorial symbol. And could be
> expanded to handle more fault sources easy enough as long as they all
> worked alike. With "work alike" defined as turning on an isolated switch
> when it faults.
>
> Take care Sven.
>
> Cheers, Gene Heskett
>

Turns out it's all fine to run them all together. Got this drawing from the
designer of the driver.


[image: error-line.jpg]
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Mpi-forum] Scheduling MPI Forum Meeting for First Week of January

[Wesley Bland via mpi-forum]

Hi all,

In today’s virtual meeting, we agreed that we should try to meet during the 
first week of January, but because of a number of holidays/conflicts, our usual 
time may not work. Here’s a Doodle poll to try to find another time to schedule 
a two hour block during that week.

https://doodle.com/poll/edc9wikfwyzs2ffd?utm_source=poll_medium=link 


Please fill out the poll by the end of the day tomorrow (as in, before I wake 
up in the US Central time zone on Friday, December 18th).

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[cobirds] Canyon towhee information, Loveland

[Jace Wesley Brasher]

Hello, I continue to see reports for the canyon towhee in west Loveland,
but can not tell if the bird has been relocated or where exactly it is.
Any further information that you can provide would be greatly appreciated.

Jace Brasher
Loveland
Larimer county

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyjgnoUbJ2h41ex6LQXnkovo8Gwg_F-2VRPnL11R-s3RHA%40mail.gmail.com.

[Mpi-forum] MPI Forum Treasurer

[Wesley Bland via mpi-forum]

Hi all,

I’d like to nominate Brian Smith from ORNL for MPI Forum Treasurer.

Thanks,
Wes
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[ceph-users] Re: Monitors not starting, getting "e3 handle_auth_request failed to assign global_id"

[Wesley Dillingham]

We had to rebuild our mons on a few occasions because of this. Only one mon
was ever dropped from quorum at a time in our case. In other scenarios with
the same error the mon was able to rejoin after thirty minutes or so. We
believe we may have tracked it down (in our case) to the upgrade of an AV /
packet inspection security technology being run on the servers. Perhaps
you've made similar updates.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn <http://www.linkedin.com/in/wesleydillingham>


On Tue, Dec 8, 2020 at 7:46 PM Wesley Dillingham 
wrote:

> We have also had this issue multiple times in 14.2.11
>
> On Tue, Dec 8, 2020, 5:11 PM  wrote:
>
>> I have same issue. My cluster runing 14.2.11 versions. What is your
>> version ceph?
>> ___
>> ceph-users mailing list -- ceph-users@ceph.io
>> To unsubscribe send an email to ceph-users-le...@ceph.io
>>
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[Mpi-forum] December 2020 Vote Results and Officer Nominations

[Wesley Bland via mpi-forum]

Hi all,

Since the voting block for this meeting ended up starting late and we couldn’t 
announce the results during the call, here they are:

Vote Topic: #327: Errata, Large Count Fixes (errata)
Yes No  Abstain Missed  Result
28  0   1   0   Passed

ANL AtosCEA Cisco   EPCCJulich  Fujitsu HLRSIBM INRIA
Intel   LLNLLANLNEC NVIDIA  ORNLParaTools   RWTHSNL 
TUM
TN Tech TACCUAB U Basel UIUCUNM UTC UTK TU Wien
Vote Topic: Ballot to approve release candidate (1st)
Yes No  Abstain Missed  Result
27  0   2   0   Passed

ANL AtosCEA Cisco   EPCCJulich  Fujitsu HLRSIBM INRIA
Intel   LLNLLANLNEC NVIDIA  ORNLParaTools   RWTHSNL 
TUM
TN Tech TACCUAB U Basel UIUCUNM UTC UTK TU Wien
You can find the full results for the meeting here:

https://www.mpi-forum.org/meetings/2020/12/votes 


So the meeting in February will be an official Final Ratification Meeting (FRM) 
and we’ll follow all of the procedures that go in that direction. I’ll remind 
everyone exactly what that means next Wednesday during the virtual meeting or 
you can refer to the slides from September here:

https://github.com/mpi-forum/mpi-forum.github.io/raw/master/slides/2020/09/2020-09-30-rcm-frm-procedures.pptx
 

 

As another reminder (and as you may have already seen), we’ve opened 
nominations for the officer positions for the MPI Forum (through the next 
release of the MPI Standard). Nominations should be sent to the main MPI Forum 
mailing list and I’ll add them to the website for the February meeting. You can 
find the full list of all nominees here:

https://www.mpi-forum.org/meetings/2021/02/agenda 


Thanks for participating in a very productive (albeit somewhat exhausting) 
meeting,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Emc-users] 7i96 multi wire input

[Sven Wesley]

Den tors 10 dec. 2020 kl 14:30 skrev andy pugh :

> On Thu, 10 Dec 2020 at 12:52, Sven Wesley  wrote:
>
> > All will ground if one fails and then all will fail. I mean, it would be
> OK
> > but less optimal.
>
> Can you definitely not afford one io per drive?
>
>
I guess I can, I also guess I got caught in a this-must-be-solved-mindset.
:)
Found the manual for the old BOB, it has what I'm looking for (a common
error pin AND a reset pin) and comes with RJ45 connectors to the drives.
The simplest solution will actually be to keep the BOB as an adapter.

But, you know, some ideas just need to be solved even if it's not needed...

All the best,
Sven

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] 7i96 multi wire input

[Sven Wesley]

Den ons 9 dec. 2020 kl 17:41 skrev Sven Wesley :

>
> Maybe my intentions have been unclear and now I'm a bit confused. The
> drives provide a high signal on one pin when they are working. If they fail
> the pin goes low. My initial thought was to connect all four pins to one
> input on the 7i96 and configure it to trigger a software stop.
> Like Gene proposed, shouldn't it work with all wires to one input with a
> diode in series on each pin?
>
> Best regards,
> Confusedius
>

Sorry if this is a double post, I believe my attachment was too big and the
post was blocked.
I just realized my own mistake. I can't wire them like I suggested. I could
probably wire all four to one input without the diodes but then I would
never see which one that actually fails (red warning LED on every drive).
All will ground if one fails and then all will fail. I mean, it would be OK
but less optimal.
Would it be possible to use optocouplers and serial to parallel adapt the
wiring? I hope my attached image makes sense but please see it as a
suggestion. I also found a sketch of the internals of the Bucck board, hope
that helps.
What do you electro ninjas think?


Bucck board design: http://www.icstation.com/images/uploads/11070_1.jpg
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] 7i96 multi wire input

[Sven Wesley]

Den ons 9 dec. 2020 kl 13:33 skrev Gene Heskett :

> On Wednesday 09 December 2020 03:52:16 Sven Wesley wrote:
>
> > Den ons 9 dec. 2020 kl 02:27 skrev Gregg Eshelman via Emc-users <
> >
> > emc-users@lists.sourceforge.net>:
> > > The way to wire an emergency stop circuit with 2 or more things that
> > > can trigger it, is to have it a normally closed circuit and every
> > > stop switch, mechanical or electronic, in series.
> > > That way when anything triggers a stop it opens the circuit, the
> > > controller senses that and stops sending motion commands, shuts off
> > > the spindle(s), pump(s) etc.
> > > What does this controller mean by "high" if "low" is grounded? If
> > > "high" is open circuit then you should be able to connect every
> > > fault sensor and a normally open E-Stop button in parallel. You'll
> > > also need to have the new control hardware and software able to be
> > > set to use a closed circuit instead of open circuit as the E-Stop
> > > condition.
> > >If "high" is something other than open circuit then things get
> > > more complicated. One may curse the engineer(s) who thought that
> > > making things more complex than open or closed was a neat idea. ;)
> > > A NC E-Stop circuit is quite fail safe because if a switch fails or
> > > a wire breaks, the circuit goes open and the machine stops. If a
> > > wire breaks in a NO circuit then the E-Stop button or sensor the
> > > broken wire goes to cannot initiate a stop.
> > >
> >   > On Tuesday, December 8, 2020, 04:19:16 PM MST, Sven Wesley <
> > >
> > > svenne.d...@gmail.com> wrote:
> > >   > Friends,
> > >   >
> > >   > I am in the process of refreshing a CNC that has been running in
> > >
> > > "temporary
> > >
> > >   > state" the last 12 years, time to give it an overhaul. I've
> > >   > found the
> > >
> > > magic
> > >
> > >   > little piece we all call 7i96. It will do magic.
> >
> > But this isn't an E-stop circuit though, it's an error signal from the
> > drive that can/should be reacted upon. It makes total sense to have an
> > active low on such wire. If the drive dies completely the signal will
> > disappear as well.
> >
> This idea came from my r-pi4 driven Sheldon lathe. I had recently
> replaced the x & z drives, which were junk box occupants when I did the
> conversion to cnc originally, with one of the new 3 phase stepper driven
> servo's a, 3NM for z and because it was shorter and its length would fit
> on the back of a new apron, a 2NM for x, both nema 23 sized. Because I'm
> using the spi driven 7i90HD and buffering it with a triplet of 7i42TA's
> which make the wiring nice and gives me 72 i/o's, I had gpio's to throw
> away. So I brought the 2 error signals in on separate pins and that
> allows me to issue a pyvcp based video advisory. Because all the r-pi4
> stuff is on the rear of the lathe, leds in that location, includingthe
> fault leds on the drivers themselves, are out of sight, so I did the
> video ouyput thing.
>
> Basically, a fault means a loss of home because it shuts down the drive,
> the machine will need to be rehomed anyway. So a fault bangs off the F2
> status, which all machine power to be removed as I have a couple 40 amp
> Solid State Relays in series with the 250 volt feed. 10 seconds of
> powerdown resets the faults, so I remove the tool, wait for the vfd
> display to quit, press F2 to re-enable machine power, which is taalied
> in the video, rehome the machine, replace the tool, and decide what to
> do so it doesn't fault again. Since I write my own gcode, thats the
> fitst thing I inspect, usually finding a mistake in the gcode. Fix that,
> reload the gcode again and hit the r key.
>
> I have not had an x caused fault yet because a 2NM motor driving that
> tiny x screw with a 2/1 reduction, is enough to damage the 8mm screw
> that moves my x, so since that screw has no replacements, I take no
> chances of stripping it. I can't even find new balls to re-stuff it
> today. And there simply is not enough space for a bigger, commonly
> available 12mm screw.
>
> These 3 phase drives have no currant setting switches, use very little
> current in normal operation as they control the current by using enough
> to attain the position and fault when they cannot do that because
> something has blocked its movement, the driver being its own PID, they
> issue the fault and shut the maqchine off if they can't follow orders.
>
> There are N

Re: [Emc-users] 7i96 multi wire input

[Sven Wesley]

Den ons 9 dec. 2020 kl 02:27 skrev Gregg Eshelman via Emc-users <
emc-users@lists.sourceforge.net>:

> The way to wire an emergency stop circuit with 2 or more things that can
> trigger it, is to have it a normally closed circuit and every stop switch,
> mechanical or electronic, in series.
> That way when anything triggers a stop it opens the circuit, the
> controller senses that and stops sending motion commands, shuts off the
> spindle(s), pump(s) etc.
> What does this controller mean by "high" if "low" is grounded? If "high"
> is open circuit then you should be able to connect every fault sensor and a
> normally open E-Stop button in parallel. You'll also need to have the new
> control hardware and software able to be set to use a closed circuit
> instead of open circuit as the E-Stop condition.
>If "high" is something other than open circuit then things get more
> complicated. One may curse the engineer(s) who thought that making things
> more complex than open or closed was a neat idea. ;)
> A NC E-Stop circuit is quite fail safe because if a switch fails or a wire
> breaks, the circuit goes open and the machine stops. If a wire breaks in a
> NO circuit then the E-Stop button or sensor the broken wire goes to cannot
> initiate a stop.

  > On Tuesday, December 8, 2020, 04:19:16 PM MST, Sven Wesley <
> svenne.d...@gmail.com> wrote:
>   > Friends,
>   >
>   > I am in the process of refreshing a CNC that has been running in
> "temporary
>   > state" the last 12 years, time to give it an overhaul. I've found the
> magic
>   > little piece we all call 7i96. It will do magic.
>

But this isn't an E-stop circuit though, it's an error signal from the
drive that can/should be reacted upon. It makes total sense to have an
active low on such wire. If the drive dies completely the signal will
disappear as well.

Regards,
Sven

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] 7i96 multi wire input

[Sven Wesley]

Den ons 9 dec. 2020 kl 01:39 skrev Gene Heskett :

> On Tuesday 08 December 2020 18:17:11 Sven Wesley wrote:
>
> > Am I totally off the chart if I wire all the drives' pin number 6
> > together and connect them to one of the inputs on the 7i96 and get it
> > to stop the program with a big alert? And maybe add a mechanical
> > switch shortcutting to ground for those panic moments?
>
> I would do the parallel but I'd put a 1n914 in series to a common point,
> So the comon point src could be ID'd, I'd put a super bright led from a 5
> volt line to each of the alarm outputs, letting you see at a glance
> which driver is issueing the alarm.
>
> Cheers, Gene Heskett
>

Nice idea, will do that!

Regards,
Sven

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[ceph-users] Re: Monitors not starting, getting "e3 handle_auth_request failed to assign global_id"

[Wesley Dillingham]

We have also had this issue multiple times in 14.2.11

On Tue, Dec 8, 2020, 5:11 PM  wrote:

> I have same issue. My cluster runing 14.2.11 versions. What is your
> version ceph?
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Re: [Emc-users] 7i96 multi wire input

[Sven Wesley]

Den ons 9 dec. 2020 kl 00:37 skrev Peter C. Wallace :

> On Wed, 9 Dec 2020, Sven Wesley wrote:
>
> > Date: Wed, 9 Dec 2020 00:17:11 +0100
> > Friends,
>
> > I am in the process of refreshing a CNC that has been running in
> "temporary
> > state" the last 12 years, time to give it an overhaul. I've found the
> magic
> > little piece we all call 7i96. It will do magic.
> > ...
> > The manual for the drive says:
> > Error line is pin number 6 in the Main connector and is a dual purpose,
> bi
> > directional line.This pin is active low, meaning that the line is
> > normally high indicating no problems and normal operation.
> > ...
>
> Am I totally off the chart if I wire all the drives' pin number 6 together
> > and connect them to one of the inputs on the 7i96 and get it to stop the
> > program with a big alert?
>
> I think this is possible if you wire the 7I96 input commom
> to +5V so the can sense a logic low. You could also
> use a 7I96 output to short the fault pin to ground
> if you wanted a software reset capability
>
> Peter Wallace
> Mesa Electronics
>

Hi Peter, thanks for your quick reply!
I'm not sure I am following you, the wire should already be high if it is
in normal state?
There is another pin on the drives for resetting a previous error, it works
the same way and an output should work. Today I use a simple push button
inside the cabinet. :)
/Sven

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] 7i96 multi wire input

[Sven Wesley]

Friends,

I am in the process of refreshing a CNC that has been running in "temporary
state" the last 12 years, time to give it an overhaul. I've found the magic
little piece we all call 7i96. It will do magic.

The servo drives have been running flawlessly and the plan is to keep them.
They have a neat error/reset feature via two pins and the old parallel port
BOB supports it. If one drive or an emergency stop is triggering the stop
pin, all drives will be halted by the BOB.
The manual for the drive says:







*Error line is pin number 6 in the Main connector and is a dual purpose, bi
directional line.This pin is ‘active low’, meaning that the line is
normally high indicating no problems andnormal operation. The drive will
stop if this pin is pulled low (grounded) by one of thesesources:EXTERNAL
activation; The line can be pulled low by an external source (CNCsoftware,
E-stop, etc).  INTERNAL activation; The line is pulled low by the drive
itself due to a faultcondition.*

Am I totally off the chart if I wire all the drives' pin number 6 together
and connect them to one of the inputs on the 7i96 and get it to stop the
program with a big alert? And maybe add a mechanical switch shortcutting to
ground for those panic moments?
If I am not totally stupid, what would the Mesa pin config look like?

All the best,
Sven

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[ovirt-users] Re: CentOS 8 is dead

[Wesley Stewart]

This is a little concerning.

But it seems pretty easy to convert:
https://www.centos.org/centos-stream/

However I would be curious to see if someone tests this with having an
active ovirt node!

On Tue, Dec 8, 2020 at 2:39 PM Strahil Nikolov via Users 
wrote:

> Hello All,
>
> I'm really worried about the following news:
> https://blog.centos.org/2020/12/future-is-centos-stream/
>
> Did anyone tried to port oVirt to SLES/openSUSE or any Debian-based
> distro ?
>
> Best Regards,
> Strahil Nikolov
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/HZC4D4OSYL64DX5VYXDJCHDNRZDRGIT6/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/W2AUQ3UFT6SHPDTRXPVHQUL2VKKCAUSR/

[ceph-users] Running Mons on msgrv2/3300 only.

[Wesley Dillingham]

We rebuilt all of our mons in one cluster such that they bind only to port 3300 
with msgrv2. Previous to this we were binding to both 6789 and 3300. All of our 
server and client components are sufficiently new (14.2.x) and we haven’t 
observed any disruption but I am inquiring if this may be problematic for any 
unforeseen reason. We don’t intend to have any older clients connecting. 
https://docs.ceph.com/en/latest/rados/configuration/msgr2/ doesn’t mention much 
about running with only v2 so I just want to make sure we aren’t setting 
ourselves up for trouble. Thanks.


--
Respectfully,

Wes Dillingham
Site Reliability Engineer IV
Storage Engineering / Ceph
wdillingham(at)godaddy.com

___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Re: [google-appengine] Google Translate API & Permissions

[wesley chun]

Thanks for your feedback Joshua. Can you take a screenshot of the Cloud
Console where you think there should be a message or that is misleading,
then go to the appropriate page in the documentation you think additional
messaging would help, and click on the "Send feedback" button in the upper
right corner of that page? The tool will also let you highlight where on
the docs page your messaging should go. This will greatly help the team
analyze your feedback and take appropriate action as necessary.

Cheers,
--Wesley

On Fri, Nov 20, 2020 at 5:33 AM Joshua Smith 
wrote:

> That worked. Thank you so much.
>
> You guys need to work on your documentation. I never could have figured
> that out myself. And the process of adding that role to the service account
> was also weird. (The UX is asking for the email of a new user, when what I
> need to add is a service account that isn’t a new user, and isn’t even
> really an email.)
>
> -Joshua
>
> On Nov 19, 2020, at 2:19 PM, 'Amit Sinha' via Google App Engine <
> google-appengine@googlegroups.com> wrote:
>
> *Hello Joshua, could you try to add the “Cloud Translation API User” role
> in the service account from IAM? As of this [1] documentation, it includes
> the permission that showing in the error.[1]
> https://cloud.google.com/iam/docs/understanding-roles#cloud-translation-roles
> <https://cloud.google.com/iam/docs/understanding-roles#cloud-translation-roles>*
> On Monday, November 16, 2020 at 2:23:03 PM UTC-5 Joshua Smith wrote:
>
>> I don’t think Google could have come up with a more confusing and
>> convoluted system for API permission management if they tried.
>>
>> So I’ve enabled the “cloud translation” API within my project.
>>
>> I have some Python (2.7, old school) code that goes:
>>
>> credentials =
>> ServiceAccountCredentials.from_json_keyfile_name(CLIENT_SECRETS_FILE,
>> scopes=['https://www.googleapis.com/auth/cloud-platform’])
>> http_auth = credentials.authorize(Http())
>> service = build("translation", "v3", http=http_auth)
>> service.projects().translateText(parent=“projects/*my-project-id-here*",body={"contents":"bonjour",
>> "targetLanguageCode":"en"}).execute()
>>
>> And I get:
>>
>> googleapiclient.errors.HttpError: > https://translation.googleapis.com/v3/projects/*my-project-id-here*:translateText?alt=json
>> returned "Cloud IAM permission 'cloudtranslate.generalModels.predict'
>> denied.">
>>
>> So it seems like I need to check some box somewhere to make this work,
>> but I can’t figure out where.
>>
>> The service account in the client secrets file is working fine when I use
>> it to hit Google Analytics from the same app. And in fact, my code to
>> access GA is almost identical except the scope and service call.
>>
>> Any ideas?
>>
>> -Joshua
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/38511647-af55-4440-b8a9-47a2d26e1f42n%40googlegroups.com
> <https://groups.google.com/d/msgid/google-appengine/38511647-af55-4440-b8a9-47a2d26e1f42n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/96693B33-8943-4948-8444-7F9ABAAAB70D%40gmail.com
> <https://groups.google.com/d/msgid/google-appengine/96693B33-8943-4948-8444-7F9ABAAAB70D%40gmail.com?utm_medium=email_source=footer>
> .
>


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
wesley chun :: @wescpy <http://twitter.com/wescpy> :: Software
Architect & Engineer
Developer Advocate at Google Cloud by day; at night...
Python training & consulting : http://CyberwebConsulting.com
"Core Python" books : http://CorePython.com
Python blog: http://wescpy.blogspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAB6eaA6qha4NWpPqtRQvSt3v86vPwJQ02j%3D_UtFT8w5m6KnHGQ%40mail.gmail.com.

[Mpi-forum] MPI Forum December Meeting Registration

[Wesley Bland via mpi-forum]

Hi all,

There are still a few folks who have not yet registered for the December 
meeting that would have expected to do so. Please do that before ASAP so we 
don’t have problems with voting on Monday morning. If you’re not sure if you’ve 
registered, you can see that here:

https://www.mpi-forum.org/meetings/2020/12/attendance 


If you need to register, you can do that here:

https://forms.gle/rRC1CqmDGMuTnZ5CA 

There are also a handful people who haven’t yet finished their review 
assignments. Please try to finish that today so we can get those fixed next 
week. Chapter committee chairs, remember that you will be responsible for a 
“reading” of each of your chapters next week so be prepared for that.

Have a good weekend.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [google-appengine] Re: CloudTasks Queue (HTTP Tasks) break when disabling AppEngine

[wesley chun]

Thanks for the feedback... I see you're referring to the NOTE sidebar here
<https://cloud.google.com/tasks/docs/creating-queues#before_you_begin>,
correct? Is your request to have a similar note placed on the Cloud Console
page to disable their App Engine apps
<https://console.cloud.google.com/appengine/settings> warning users it will
also disable their Task Queues, regardless of where the task handlers are
(GAE or not)?

If so, go to that page in the docs, in the upper right corner, click the
"Send Feedback" button and use the tool to submit a screenshot of that NOTE
and let us know this warning should also appear on that Cloud Console page.
This will give weight to any bug filed (when customers experience issues
like this).

I think the reason you have to have an *enabled* App Engine "app" (in the
console even if you don't actually have any code running on App Engine) is
that Cloud Tasks originated from App Engine, and they haven't fully
migrated it away from GAE yet.

Thanks,
--Wesley

On Mon, Nov 30, 2020 at 2:04 PM Micah Thomas  wrote:

> Wesley,
>
> Our application uses HTTP handlers that are running in kubernetes on the
> same project, we don't use any appengine targets.
> The issue is that even w/o any handlers running in appengine, if I disable
> the appengine project, cloud tasks stop working.
>
> I now see that the official docs page has a note: The appengine project
> must stay enabled for queues to function.
> It would be better for user experience if this info is shown when you go
> to disable the appengine project so that a user is not surprised when the
> queues stop working.
>
> On Monday, November 30, 2020 at 2:38:33 PM UTC-7 Wesley C (Google) wrote:
>
>> There are 2 different types of (push) tasks that Cloud Tasks can handle,
>> and it depends on *where* the tasks are handled. These are called
>> "targets," and you can have App Engine targets, meaning the tasks run on
>> and are handled by App Engine, or generic HTTP targets, meaning the tasks
>> are hosted and are handled elsewhere, say a VM, Cloud Functions, etc. You
>> can read more about both types in this official docs page
>> <https://cloud.google.com/tasks/docs/dual-overview>.
>>
>> Focusing more specifically on your question, if your target tasks are
>> hosted on App Engine, then you project/app should *not* be disabled, but if
>> it is a standard HTTP target, you don't need an App Engine app for *that*
>> case. Hope this helps!
>>
>> On Sat, Nov 21, 2020 at 12:32 PM Micah Thomas 
>> wrote:
>>
>>> Thanks for pointing that out.
>>>
>>> I didn't get that impression from anywhere else, and it was confusing
>>> that cloud tasks have it's own page in google cloud if it depends on
>>> appengine.
>>> Anyway, I'll probably look into another system, and just keep the
>>> appengine app running till I migrate our queues over to something else.
>>>
>>> On Friday, November 20, 2020 at 7:24:52 AM UTC-7 jstsetinin wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> Thak you for your question.
>>>>
>>>> According to our documentation "You must have an enabled App Engine
>>>> application in your project to run your queue." [1]
>>>> It is not possible to make it work without Appengine.
>>>>
>>>> [1] https://cloud.google.com/tasks/docs/quickstart-appengine
>>>> On Friday, 20 November 2020 at 01:43:25 UTC+1 micaht...@gmail.com
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am having trouble with Cloud Tasks (HTTP Request Tasks) breaking
>>>>> when I disable my app-engine application. For the time being I've
>>>>> re-enabled the app-engine application to get the cloud tasks queue to keep
>>>>> working. I thought Cloud Tasks was a separate project, and does not depend
>>>>> on appengine.
>>>>>
>>>>> Not sure who I should be talking to, if this is not the right
>>>>> group/place.
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAB6eaA7qzx0LjismcEm%3DWxHaz_yF4TkMyH7DY9WUzVUo0RQ8iQ%40mail.gmail.com.

[Mpi-forum] Virtual Meeting Today

[Wesley Bland via mpi-forum]

Hi all,

For anyone who was trying to join the virtual meeting early, sorry about any 
confusion, but the link to do so has changed. Apparently the old meeting series 
ended after the last meeting. Please go get the latest link from the wiki page 
here (log in to GitHub if you see 404 errors):

https://github.com/mpi-forum/mpi-standard/wiki/Virtual-Forum-Meeting-Information
 


Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [google-appengine] Re: CloudTasks Queue (HTTP Tasks) break when disabling AppEngine

[wesley chun]

There are 2 different types of (push) tasks that Cloud Tasks can handle,
and it depends on *where* the tasks are handled. These are called
"targets," and you can have App Engine targets, meaning the tasks run on
and are handled by App Engine, or generic HTTP targets, meaning the tasks
are hosted and are handled elsewhere, say a VM, Cloud Functions, etc. You
can read more about both types in this official docs page
<https://cloud.google.com/tasks/docs/dual-overview>.

Focusing more specifically on your question, if your target tasks are
hosted on App Engine, then you project/app should *not* be disabled, but if
it is a standard HTTP target, you don't need an App Engine app for *that*
case. Hope this helps!

On Sat, Nov 21, 2020 at 12:32 PM Micah Thomas 
wrote:

> Thanks for pointing that out.
>
> I didn't get that impression from anywhere else, and it was confusing that
> cloud tasks have it's own page in google cloud if it depends on appengine.
> Anyway, I'll probably look into another system, and just keep the
> appengine app running till I migrate our queues over to something else.
>
> On Friday, November 20, 2020 at 7:24:52 AM UTC-7 jstsetinin wrote:
>
>>
>> Hello,
>>
>> Thak you for your question.
>>
>> According to our documentation "You must have an enabled App Engine
>> application in your project to run your queue." [1]
>> It is not possible to make it work without Appengine.
>>
>> [1] https://cloud.google.com/tasks/docs/quickstart-appengine
>> On Friday, 20 November 2020 at 01:43:25 UTC+1 micaht...@gmail.com wrote:
>>
>>> Hello,
>>>
>>> I am having trouble with Cloud Tasks (HTTP Request Tasks) breaking when
>>> I disable my app-engine application. For the time being I've re-enabled the
>>> app-engine application to get the cloud tasks queue to keep working. I
>>> thought Cloud Tasks was a separate project, and does not depend on
>>> appengine.
>>>
>>> Not sure who I should be talking to, if this is not the right
>>> group/place.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/f09a677a-7f5e-424f-bcfb-5ddd5b7ead78n%40googlegroups.com
> <https://groups.google.com/d/msgid/google-appengine/f09a677a-7f5e-424f-bcfb-5ddd5b7ead78n%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
wesley chun :: @wescpy <http://twitter.com/wescpy> :: Software
Architect & Engineer
Developer Advocate at Google Cloud by day; at night...
Python training & consulting : http://CyberwebConsulting.com
"Core Python" books : http://CorePython.com
Python blog: http://wescpy.blogspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAB6eaA4C3yYTfqVBYHdk0hKz80yenAnAQXTeWoaxvCY-jf%3Ddrw%40mail.gmail.com.

Re: [google-appengine] Re: Python App

[wesley chun]

Unfortunately the code you have is a Python command-line script, meaning
you can't use Google Cloud serverless platforms (App Engine, Cloud
Functions, Cloud Run) unless you either add API endpoints and data
serialization, or turn it into a full web app.

Based on what you have right now, you can try to run it elsewhere: 1) in
Cloud Shell, 2) on a Compute Engine VM (most users get an f1-micro free
each month), 3) Kubernetes Engine (more complex, but you seem have a
`google.yml` file for it), or 4) on your own computer.

On Sun, Nov 29, 2020 at 11:52 AM Zain Basit  wrote:

> https://github.com/zainbasit/GoogleCloudPlatform this is the app I want
> to deploy and execute, cloud functions didn't work.
>
> On Monday, November 30, 2020 at 12:28:24 AM UTC+5 yananc wrote:
>
>> *Hello, If you would like to know general information on how to deploy
>> and run Python apps on App Engine, please refer to the Quickstart for
>> Python 3 in App Engine Standard
>> <https://cloud.google.com/appengine/docs/standard/python3/quickstart> and
>> Quickstart for Python in App Engine Flexible
>> <https://cloud.google.com/appengine/docs/flexible/python/quickstart> for
>> detailed steps and sample Hello World apps for demonstration. If you have
>> any specific questions or issues regarding the matter, please kindly
>> elaborate so it would be much easier to get them answered.*
>>
>> On Sunday, November 29, 2020 at 9:58:09 AM UTC-5 zainb...@gmail.com
>> wrote:
>>
>>> Want to execute and run python app
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/294a84ea-b75f-43d4-a9bf-be5304612fd8n%40googlegroups.com
> <https://groups.google.com/d/msgid/google-appengine/294a84ea-b75f-43d4-a9bf-be5304612fd8n%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
wesley chun :: @wescpy <http://twitter.com/wescpy> :: Software
Architect & Engineer
Developer Advocate at Google Cloud by day; at night...
Python training & consulting : http://CyberwebConsulting.com
"Core Python" books : http://CorePython.com
Python blog: http://wescpy.blogspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAB6eaA4CekH20nAPegM1V6vvemAYBW29p-kXQXKpoVdND%2BAsKg%40mail.gmail.com.

[Mpi-forum] MPI 4.0 RC Reviews and Corrections Action Items

[Wesley Bland via mpi-forum]

Hi all,

We’re getting close the release candidate meeting for MPI 4.0 next week and 
many of you have already submitted your reviews for your assigned section. If 
you haven’t done so already, please do that soon. If you won’t be able to do 
it, please let me know that too as I have a couple of people who have 
volunteered to help out. You should have received a link to the Google 
spreadsheet a couple of weeks ago. I don’t want to send it on this list since 
the document is editable. If you’ve lost that link, reply to me and I’ll send 
it to you again.

For those of you on chapter committees, please be looking at the reviews for 
your chapters that have already come in. The more items we can fix before or 
during the RCM next week, the easier things will be for us procedurally. This 
still includes things that were brought up earlier in the year, but weren’t yet 
addressed for the RC. There is still time to fix those and make MPI 4.0 as good 
as possible.

One thing that would be helpful is for everyone to take a look at the issues in 
this board:

https://github.com/mpi-forum/mpi-issues/projects/2#card-49698029 


Anything in the Triage list that’s assigned to you can be addressed right now 
and still make it into MPI 4.0. You can even filter to include things assigned 
to you by typing "asssignee:” in the search box on the 
right-hand side of the window. If you plan to work on any of those items, 
please drag them into the appropriate column (from Triage to “To Do” or “in 
Progress”). That will be very helpful and move things along for the RCM next 
week where we will have to go through each item in that list to make a decision 
about it anyway.

This Wednesday during the virtual meeting time (10AM US Central), we’ll go 
through as many of these issues as possible to clear the way for other things 
next week. Please try to attend if you can.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[PATCH] usb: dwc3: gadget: Restart DWC3 gadget when enabling pullup

[Wesley Cheng]

usb_gadget_deactivate/usb_gadget_activate does not execute the UDC start
operation, which may leave EP0 disabled and event IRQs disabled when
re-activating the function. Move the enabling/disabling of USB EP0 and
device event IRQs to be performed in the pullup routine.

Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the
controller")

Reported-by: Michael Tretter 
Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/gadget.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 5d879b7606d5..922c8b76e534 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1988,6 +1988,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int 
is_on, int suspend)
 
 static void dwc3_gadget_disable_irq(struct dwc3 *dwc);
 static void __dwc3_gadget_stop(struct dwc3 *dwc);
+static int __dwc3_gadget_start(struct dwc3 *dwc);
 
 static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
 {
@@ -2050,6 +2051,8 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
dwc->ev_buf->lpos = (dwc->ev_buf->lpos + count) %
dwc->ev_buf->length;
}
+   } else {
+   __dwc3_gadget_start(dwc);
}
 
ret = dwc3_gadget_run_stop(dwc, is_on, false);
@@ -2224,10 +2227,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
 
dwc->gadget_driver  = driver;
-
-   if (pm_runtime_active(dwc->dev))
-   __dwc3_gadget_start(dwc);
-
spin_unlock_irqrestore(>lock, flags);
 
return 0;
@@ -2253,13 +2252,6 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
unsigned long   flags;
 
spin_lock_irqsave(>lock, flags);
-
-   if (pm_runtime_suspended(dwc->dev))
-   goto out;
-
-   __dwc3_gadget_stop(dwc);
-
-out:
dwc->gadget_driver  = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[ceph-users] Mon's falling out of quorum, require rebuilding. Rebuilt with only V2 address.

[Wesley Dillingham]

We have had multiple clusters experiencing the following situation over the
past few months on both 14.2.6 and 14.2.11. On a few instances it seemed
random , in a second situation we had temporary networking disruption, in a
third situation we accidentally made some osd changes which caused certain
OSDs to reach the hard limit of too many pgs-per-osd and said PGs were
stuck inactive. Regardless of the scenario one monitor always falls out of
quorum and seemingly can't rejoin and its logs contain the following:

2020-11-18 05:34:54.113 7f14286d9700  1 mon.a2plcephmon01@2(probing) e30
handle_auth_request failed to assign global_id
2020-11-18 05:34:54.295 7f14286d9700 -1 mon.a2plcephmon01@2(probing) e30
handle_auth_bad_method hmm, they didn't like 2 result (13) Permission denied
2020-11-18 05:34:55.397 7f14286d9700  1 mon.a2plcephmon01@2(probing) e30
handle_auth_request failed to assign global_id


Ultimately, we take the quick route of rebuilding the mon by wiping its DB
and re-doing a mkfs and rejoining the quorum using:

sudo -u ceph ceph-mon -i a2plcephmon01 --public-addr 10.1.1.1:3300

Luckily we have never dropped below 50% in quorum so far but we are very
interested in preventing this from happening going forward. Inspecting
"ceph mon dump" on the given clusters I see that all of the rebuilt mons
use only msgrv2 on 3300 but all of the mons that never required rebuilding
are using v1 and v2 addressing. So my question are:

- Does this monitor failure sound familiar?
- Is it problematic the manner in which we are rebuilding mons and it only
lands them on using msgr v2 or should we be using v2 only on an
all-nautilus cluster?

Thanks for any insight.


Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Re: [PATCH v4] usb: dwc3: Stop active transfers before halting the controller

[Wesley Cheng]

On 11/18/2020 2:14 AM, Michael Tretter wrote:
> Hello,
> 
> On Mon, 28 Sep 2020 17:20:59 -0700, Wesley Cheng wrote:
>> In the DWC3 databook, for a device initiated disconnect or bus reset, the
>> driver is required to send dependxfer commands for any pending transfers.
>> In addition, before the controller can move to the halted state, the SW
>> needs to acknowledge any pending events.  If the controller is not halted
>> properly, there is a chance the controller will continue accessing stale or
>> freed TRBs and buffers.
> 
> This patch causes a regression when using the uvc gadget with the dwc3 gadget
> driver, which causes host to not be able to enumerate the USB device.
> 
> The regression can be reproduced as follows:
> 
> Configure the uvc gadget via configfs, which in the end binds to the driver
> and calls dwc3_gadget_start. Start the uvc-gadget user space application,
> which activates the function and the gadget and calls pullup enable. The UVC
> Device is now detected by a USB host.
> 
> Stop the uvc gadget application, which deactivates the gadget, calls pullup
> disable and, thus, stops the dwc3 gadget.
> 
Hi Michael,

Thanks for the analysis.  I think specifically, the f_uvc will use the
usb_function_deactivate() API to disable the pullup (w/o calling
udc_stop()) and using usb_function_activate() to do the opposite.  These
are triggered when an application opens/closes the V4L2 device. (your
application)

> Restart the uvc gadget application; the gadget is activated and pullup enable
> is called, but the dwc3 gadget is not started.
> 

Seems like the deactivate/activate calls avoid any UDC start stop
operations, and only use the pullup executions to issue a soft disconnect.

> The USB Host shows the following error messages and the USB device cannot be
> enumerated.
> 
>   usb 3-1.1: Device not responding to setup address.
>   usb 3-1.1: Device not responding to setup address.
>   usb 3-1.1: device not accepting address 10, error -71
>   usb 3-1.1: Device not responding to setup address.
>   usb 3-1.1: Device not responding to setup address.
>   usb 3-1.1: device not accepting address 11, error -71
>   usb 3-1-port1: unable to enumerate USB device
> 
>>
>> Signed-off-by: Wesley Cheng 
>> Reviewed-by: Thinh Nguyen 
>>
>> ---
>> Changes in v4:
>>  - Updated comments to reference DWC3 databook sections and added direct
>>quotes.
>>  - Changed the stop active transfer EP loop to use dwc->num_eps.
>>  - Moved to using dwc3_gadget_disable_irq/synchronize_irq instead of
>>enable_irq/disable_irq for ensuring the interrupt handler is not pending.
>>
>> Changes in v3:
>>  - Removed DWC3_EP_ENABLED check from dwc3_gadget_stop_active_transfers()
>>as dwc3_stop_active_transfer() has a check already in place.
>>  - Calling __dwc3_gadget_stop() which ensures that DWC3 interrupt events
>>are cleared, and ep0 eps are cleared for the pullup disabled case.  Not
>>required to call __dwc3_gadget_start() on pullup enable, as the
>>composite driver will execute udc_start() before calling pullup().
> 
> This change seems to be related to the regression. Maybe it is required to
> call __dwc3_gadget_start() on pullup enable, but I am not sure, how this
> should be handled.
> 
> Michael
> 

Definitely, in this situation, we would not call the udc_start()
callback, which will affect the functionality after re-enabling the
device.  I wonder why the deactivate/activate routines don't explicitly
need to start/stop the UDC?

Thanks
Wesley Cheng

>>
>> Changes in v2:
>>  - Moved cleanup code to the pullup() API to differentiate between device
>>disconnect and hibernation.
>>  - Added cleanup code to the bus reset case as well.
>>  - Verified the move to pullup() did not reproduce the problen using the
>>same test sequence.
>>
>> Verified fix by adding a check for ETIMEDOUT during the run stop call.
>> Shell script writing to the configfs UDC file to trigger disconnect and
>> connect.  Batch script to have PC execute data transfers over adb (ie adb
>> push)  After a few iterations, we'd run into a scenario where the
>> controller wasn't halted.  With the following change, no failed halts after
>> many iterations.
>> ---
>>  drivers/usb/dwc3/ep0.c|  2 +-
>>  drivers/usb/dwc3/gadget.c | 66 ++-
>>  2 files changed, 66 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index 59f2e8c31bd1..456aa87e8778 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
&

Re: [Mpi-forum] December 2020 Registration Reminder

[Wesley Bland via mpi-forum]

It’s going through a bunch of unshorteners I guess, but otherwise it’s the 
same. Everything worked for me just now. You can try this link instead. 

https://docs.google.com/forms/d/e/1FAIpQLSef9c1eAj_nbaHgBNN7-tDcubHpnwAvrJBipjPmy38YGAjVgw/viewform
 
<https://docs.google.com/forms/d/e/1FAIpQLSef9c1eAj_nbaHgBNN7-tDcubHpnwAvrJBipjPmy38YGAjVgw/viewform>
 

> On Nov 17, 2020, at 3:50 PM, Ignacio Laguna via mpi-forum 
>  wrote:
> 
> Hi Wesley,
> 
> This is weird but I'm getting a "This site can’t be reached" error with this 
> link... Is this link different from the usual one?
> 
> Ignacio
> 
> 
> On 11/16/20 7:22 AM, Wesley Bland via mpi-forum wrote:
>> Hi all,
>> This is a reminder to register for the December 2020 meeting. You can do so 
>> quickly here:
>> https://forms.gle/rRC1CqmDGMuTnZ5CA
>> Thanks,
>> Wes
>> ___
>> mpi-forum mailing list
>> mpi-forum@lists.mpi-forum.org
>> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
> ___
> mpi-forum mailing list
> mpi-forum@lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[Mpi-forum] December 2020 Registration Reminder

[Wesley Bland via mpi-forum]

Hi all,

This is a reminder to register for the December 2020 meeting. You can do so 
quickly here:

https://forms.gle/rRC1CqmDGMuTnZ5CA 

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[Mpi-forum] December 2020 Vote Announcement

[Wesley Bland via mpi-forum]

Hi all,

I have one proposal that needs a vote at the December 2020 meeting. This will 
be the second vote:

Add MPI_Remove_error_class, MPI_Remove_error_code, MPI_Remove_error_string

Issue - https://github.com/mpi-forum/mpi-issues/issues/283 

PR - https://github.com/mpi-forum/mpi-standard/pull/166 
 

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[PATCH 3/3] usb: gadget: configfs: Add a specific configFS reset callback

[Wesley Cheng]

In order for configFS based USB gadgets to set the proper charge current
for bus reset scenarios, expose a separate reset callback to set the
current to 100mA based on the USB battery charging specification.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/gadget/configfs.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 56051bb97349..80ca7ff2fb97 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1481,6 +1481,28 @@ static void configfs_composite_disconnect(struct 
usb_gadget *gadget)
spin_unlock_irqrestore(>spinlock, flags);
 }
 
+static void configfs_composite_reset(struct usb_gadget *gadget)
+{
+   struct usb_composite_dev *cdev;
+   struct gadget_info *gi;
+   unsigned long flags;
+
+   cdev = get_gadget_data(gadget);
+   if (!cdev)
+   return;
+
+   gi = container_of(cdev, struct gadget_info, cdev);
+   spin_lock_irqsave(>spinlock, flags);
+   cdev = get_gadget_data(gadget);
+   if (!cdev || gi->unbind) {
+   spin_unlock_irqrestore(>spinlock, flags);
+   return;
+   }
+
+   composite_reset(gadget);
+   spin_unlock_irqrestore(>spinlock, flags);
+}
+
 static void configfs_composite_suspend(struct usb_gadget *gadget)
 {
struct usb_composite_dev *cdev;
@@ -1530,7 +1552,7 @@ static const struct usb_gadget_driver 
configfs_driver_template = {
.unbind = configfs_composite_unbind,
 
.setup  = configfs_composite_setup,
-   .reset  = configfs_composite_disconnect,
+   .reset  = configfs_composite_reset,
.disconnect = configfs_composite_disconnect,
 
.suspend= configfs_composite_suspend,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/3] Add vbus draw support to DWC3

[Wesley Cheng]

Some devices are connected to standard downstream ports (SDP) and draw current
from them.  The current rates are defined in the BC1.2 specification, and
highlights the different charge rates depending on the device state.  The DWC3
gadget does not currently have a mechanism to notify external drivers about
how much current can be drawn.

The current rates are notified by the USB gadget layer, and the DWC3 gadget will
propagate this potentially to external charger drivers.  Also, the USB gadget
needs to be fixed to only allow 100mA current draw when receiving a bus reset
from the host, as the BC1.2 specification states that this is the max current
draw possible when in the connected and unconfigured state.

Wesley Cheng (3):
  usb: dwc3: gadget: Introduce a DWC3 VBUS draw callback
  usb: gadget: composite: Split composite reset and disconnect
  usb: gadget: configfs: Add a specific configFS reset callback

 drivers/usb/dwc3/gadget.c  | 11 +++
 drivers/usb/gadget/composite.c | 21 +++--
 drivers/usb/gadget/configfs.c  | 24 +++-
 include/linux/usb/composite.h  |  2 ++
 4 files changed, 55 insertions(+), 3 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/3] usb: dwc3: gadget: Introduce a DWC3 VBUS draw callback

[Wesley Cheng]

Some devices support charging while in device mode.  In these situations,
the USB gadget will notify the DWC3 gadget driver to modify the current
based on the enumeration and device state.  The usb_phy_set_power() API
will allow external charger entities to adjust the charge current through
the notifier block.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/gadget.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c145da1d8ba5..69122f66978e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2387,6 +2387,16 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
spin_unlock_irqrestore(>lock, flags);
 }
 
+static int dwc3_gadget_vbus_draw(struct usb_gadget *g, unsigned int mA)
+{
+   struct dwc3 *dwc = gadget_to_dwc(g);
+
+   if (dwc->usb2_phy)
+   return usb_phy_set_power(dwc->usb2_phy, mA);
+
+   return 0;
+}
+
 static const struct usb_gadget_ops dwc3_gadget_ops = {
.get_frame  = dwc3_gadget_get_frame,
.wakeup = dwc3_gadget_wakeup,
@@ -2396,6 +2406,7 @@ static const struct usb_gadget_ops dwc3_gadget_ops = {
.udc_stop   = dwc3_gadget_stop,
.udc_set_speed  = dwc3_gadget_set_speed,
.get_config_params  = dwc3_gadget_config_params,
+   .vbus_draw  = dwc3_gadget_vbus_draw,
 };
 
 /* -- 
*/
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/3] usb: gadget: composite: Split composite reset and disconnect

[Wesley Cheng]

Add a specific composite reset API to differentiate between disconnect and
reset events.  This is needed for adjusting the current draw accordingly
based on the USB battery charging specification.  The device is only allowed
to draw the 500/900 mA (HS/SS) while in the CONFIGURED state, and only 100 mA
in the connected and UNCONFIGURED state.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/gadget/composite.c | 21 +++--
 include/linux/usb/composite.h  |  2 ++
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 05b176c82cc5..a41f7fe4b518 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -2036,7 +2036,7 @@ composite_setup(struct usb_gadget *gadget, const struct 
usb_ctrlrequest *ctrl)
return value;
 }
 
-void composite_disconnect(struct usb_gadget *gadget)
+static void __composite_disconnect(struct usb_gadget *gadget)
 {
struct usb_composite_dev*cdev = get_gadget_data(gadget);
unsigned long   flags;
@@ -2053,6 +2053,23 @@ void composite_disconnect(struct usb_gadget *gadget)
spin_unlock_irqrestore(>lock, flags);
 }
 
+void composite_disconnect(struct usb_gadget *gadget)
+{
+   usb_gadget_vbus_draw(gadget, 0);
+   __composite_disconnect(gadget);
+}
+
+void composite_reset(struct usb_gadget *gadget)
+{
+   /*
+* Section 1.4.13 Standard Downstream Port of the USB battery charging
+* specification v1.2 states that a device connected on a SDP shall only
+* draw at max 100mA while in a connected, but unconfigured state.
+*/
+   usb_gadget_vbus_draw(gadget, 100);
+   __composite_disconnect(gadget);
+}
+
 /*-*/
 
 static ssize_t suspended_show(struct device *dev, struct device_attribute 
*attr,
@@ -2373,7 +2390,7 @@ static const struct usb_gadget_driver 
composite_driver_template = {
.unbind = composite_unbind,
 
.setup  = composite_setup,
-   .reset  = composite_disconnect,
+   .reset  = composite_reset,
.disconnect = composite_disconnect,
 
.suspend= composite_suspend,
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 2040696d75b6..0d8a71471512 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -525,6 +525,8 @@ extern struct usb_string *usb_gstrings_attach(struct 
usb_composite_dev *cdev,
 extern int usb_string_ids_n(struct usb_composite_dev *c, unsigned n);
 
 extern void composite_disconnect(struct usb_gadget *gadget);
+extern void composite_reset(struct usb_gadget *gadget);
+
 extern int composite_setup(struct usb_gadget *gadget,
const struct usb_ctrlrequest *ctrl);
 extern void composite_suspend(struct usb_gadget *gadget);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [google-appengine] Re: import 2nd library

[wesley chun]

That's quite odd John. Can you temporarily rename your main.py and deploy
this code as main.py and run it?

from flask import Flask
from google import cloud

app = Flask(__name__)

@app.route('/')
def hello_world():
return 'Hello, World!'

Pls reply with what shows up in your App Engine dashboard
<https://console.cloud.google.com/appengine> down in the "Application
Errors" section.
Also paste relevant lines from your app.yaml (or the whole thing).

Thanks,
--Wesley

On Wed, Nov 11, 2020 at 12:17 PM John Iacovacci 
wrote:

> I've isolated the problem down to my app engine python code not allowing
> me to import more than one module. Even a simple hello world app will only
> allow me to implement one import. Every time I add a module to any of my
> program I get errors.
>
> On Wed, Nov 11, 2020 at 2:58 PM 'Elliott (Cloud Platform Support)' via
> Google App Engine  wrote:
>
>> Hello,
>>
>> To isolate the problem, does this code run locally on your machine?
>>
>> On Wednesday, November 11, 2020 at 12:18:48 PM UTC-5 john.ia...@gmail.com
>> wrote:
>>
>>> I'm trying to import the datastore module(or anytime I try to import a
>>> second module for that matter) in my app engine standard code.
>>>
>>> I've virtually tried every combination and I'm getting either
>>>
>>> Error: Server ErrorThe server encountered an error and could not
>>> complete your request.
>>>
>>> Please try again in 30 seconds.
>>>
>>>
>>> or 502 Gateway ngix errors.
>>>
>>>
>>> Any thoughts?
>>>
>>>
>>> Thanks
>>>
>>>
>>> John Iacovacci
>>>
>>> main.py
>>> from flask import Flask, request, render_template
>>>
>>> # START Translate requirements
>>> from google.cloud import translate_v2 as translate
>>> translate_client = translate.Client()
>>>
>>> import datastore
>>> # END Translate requirements
>>>
>>>
>>> app = Flask(__name__)   # Flask is the web framework we're using
>>>
>>>
>>> @app.route('/', methods=['POST','GET']) # This defines when the 
>>> function below will be called
>>> def translate():
>>> if request.method == 'POST':
>>>
>>> # This code will run if a POST is received
>>>
>>> data = request.form.to_dict(flat=True)  # Reads the body of the 
>>> post request and assigns it to the "data" variable
>>>
>>> result = translate_client.translate(data['inputText'], 
>>> target_language=data["toLang"]) # Sends data to the translate API
>>>
>>> return 
>>> render_template('index.html',translatedText=result['translatedText'])# 
>>> Renders the page with the response
>>>
>>> else:
>>>
>>> # This code will run if a GET is received
>>> return render_template('index.html')
>>>
>>>
>>> # Don't worry about this part
>>> if __name__ == '__main__':
>>> app.run(host='127.0.0.1', port=8080, debug=True)
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-appengine+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-appengine/02857814-1a89-4d13-b0cb-eaa593e2dba9n%40googlegroups.com
>> <https://groups.google.com/d/msgid/google-appengine/02857814-1a89-4d13-b0cb-eaa593e2dba9n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/CADTT8SQZP_svALjuaUY_SFf%2Bdim%2BV_uGZHHPmruXFGqbvZyMvA%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-appengine/CADTT8SQZP_svALjuaUY_SFf%2Bdim%2BV_uGZHHPmruXFGqbvZyMvA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
wesley chun :: @wescpy <http://twitter.com/wescpy> :: Software
Architect & Engineer
Developer Advocate at Google Cloud by day; at night...
Python training & consulting : http://CyberwebConsulting.com
"Core Python" books : http://CorePython.com
Python blog: http://wescpy.blogspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAB6eaA50EiJne-8syMHXbHyuYT30Kk4NkesDcb9vwRr0avSF6g%40mail.gmail.com.

[Mpi-forum] No Virtual Meeting Today

[Wesley Bland via mpi-forum]

Hi all,

There will be no virtual meeting today. Bill is getting the last few things 
merged into the mpi-4.x branch and will be creating the RC over the next day or 
two. I’ll get that divided up for people to review and we’ll discuss that next 
week.

Thanks,
Wes
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[PATCH v2 2/2] usb: dwc3: gadget: Preserve UDC max speed setting

[Wesley Cheng]

The USB gadget/UDC driver can restrict the DWC3 controller speed using
dwc3_gadget_set_speed().  Store this setting into a variable, in order for
this setting to persist across controller resets due to runtime PM.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/core.h   |   1 +
 drivers/usb/dwc3/gadget.c | 108 --
 2 files changed, 58 insertions(+), 51 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 2f04b3e42bf1..390d3deef0ba 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1119,6 +1119,7 @@ struct dwc3 {
u32 nr_scratch;
u32 u1u2;
u32 maximum_speed;
+   u32 gadget_max_speed;
 
u32 ip;
 
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index babf977cadc0..c145da1d8ba5 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1941,6 +1941,61 @@ static void dwc3_stop_active_transfers(struct dwc3 *dwc)
}
 }
 
+static void __dwc3_gadget_set_speed(struct dwc3 *dwc)
+{
+   u32 reg;
+
+   reg = dwc3_readl(dwc->regs, DWC3_DCFG);
+   reg &= ~(DWC3_DCFG_SPEED_MASK);
+
+   /*
+* WORKAROUND: DWC3 revision < 2.20a have an issue
+* which would cause metastability state on Run/Stop
+* bit if we try to force the IP to USB2-only mode.
+*
+* Because of that, we cannot configure the IP to any
+* speed other than the SuperSpeed
+*
+* Refers to:
+*
+* STAR#9000525659: Clock Domain Crossing on DCTL in
+* USB 2.0 Mode
+*/
+   if (DWC3_VER_IS_PRIOR(DWC3, 220A) &&
+   !dwc->dis_metastability_quirk) {
+   reg |= DWC3_DCFG_SUPERSPEED;
+   } else {
+   switch (dwc->gadget_max_speed) {
+   case USB_SPEED_LOW:
+   reg |= DWC3_DCFG_LOWSPEED;
+   break;
+   case USB_SPEED_FULL:
+   reg |= DWC3_DCFG_FULLSPEED;
+   break;
+   case USB_SPEED_HIGH:
+   reg |= DWC3_DCFG_HIGHSPEED;
+   break;
+   case USB_SPEED_SUPER:
+   reg |= DWC3_DCFG_SUPERSPEED;
+   break;
+   case USB_SPEED_SUPER_PLUS:
+   if (DWC3_IP_IS(DWC3))
+   reg |= DWC3_DCFG_SUPERSPEED;
+   else
+   reg |= DWC3_DCFG_SUPERSPEED_PLUS;
+   break;
+   default:
+   dev_err(dwc->dev, "invalid speed (%d)\n", 
dwc->gadget_max_speed);
+
+   if (DWC3_IP_IS(DWC3))
+   reg |= DWC3_DCFG_SUPERSPEED;
+   else
+   reg |= DWC3_DCFG_SUPERSPEED_PLUS;
+   }
+   }
+   dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+}
+
 static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
 {
u32 reg;
@@ -1963,6 +2018,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int 
is_on, int suspend)
if (dwc->has_hibernation)
reg |= DWC3_DCTL_KEEP_CONNECT;
 
+   __dwc3_gadget_set_speed(dwc);
dwc->pullups_connected = true;
} else {
reg &= ~DWC3_DCTL_RUN_STOP;
@@ -2325,59 +2381,9 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
 {
struct dwc3 *dwc = gadget_to_dwc(g);
unsigned long   flags;
-   u32 reg;
 
spin_lock_irqsave(>lock, flags);
-   reg = dwc3_readl(dwc->regs, DWC3_DCFG);
-   reg &= ~(DWC3_DCFG_SPEED_MASK);
-
-   /*
-* WORKAROUND: DWC3 revision < 2.20a have an issue
-* which would cause metastability state on Run/Stop
-* bit if we try to force the IP to USB2-only mode.
-*
-* Because of that, we cannot configure the IP to any
-* speed other than the SuperSpeed
-*
-* Refers to:
-*
-* STAR#9000525659: Clock Domain Crossing on DCTL in
-* USB 2.0 Mode
-*/
-   if (DWC3_VER_IS_PRIOR(DWC3, 220A) &&
-   !dwc->dis_metastability_quirk) {
-   reg |= DWC3_DCFG_SUPERSPEED;
-   } else {
-   switch (speed) {
-   case USB_SPEED_LOW:
-   reg |= DWC3_DCFG_LOWSPEED;
-   break;
-   case USB_SPEED_FULL:
-   reg |= DWC3_DCFG_FULLSPEED;
-   break;
-   case USB_SPEED_HIGH:
-   reg |= DWC3_DCFG_HIGHSPEED;
-   break;
-   

[PATCH v2 1/2] usb: dwc3: gadget: Allow runtime suspend if UDC unbinded

[Wesley Cheng]

The DWC3 runtime suspend routine checks for the USB connected parameter to
determine if the controller can enter into a low power state.  The
connected state is only set to false after receiving a disconnect event.
However, in the case of a device initiated disconnect (i.e. UDC unbind),
the controller is halted and a disconnect event is never generated.  Set
the connected flag to false if issuing a device initiated disconnect to
allow the controller to be suspended.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/gadget.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 5d879b7606d5..babf977cadc0 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2012,6 +2012,17 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
}
}
 
+   /*
+* Check the return value for successful resume, or error.  For a
+* successful resume, the DWC3 runtime PM resume routine will handle
+* the run stop sequence, so avoid duplicate operations here.
+*/
+   ret = pm_runtime_get_sync(dwc->dev);
+   if (!ret || ret < 0) {
+   pm_runtime_put(dwc->dev);
+   return 0;
+   }
+
/*
 * Synchronize any pending event handling before executing the 
controller
 * halt routine.
@@ -2050,10 +2061,12 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
dwc->ev_buf->lpos = (dwc->ev_buf->lpos + count) %
dwc->ev_buf->length;
}
+   dwc->connected = false;
}
 
ret = dwc3_gadget_run_stop(dwc, is_on, false);
spin_unlock_irqrestore(>lock, flags);
+   pm_runtime_put(dwc->dev);
 
return ret;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 0/2] Allow DWC3 runtime suspend if UDC is unbinded

[Wesley Cheng]

Changes in v2:
 - Modified logic for executing the runtime PM resume.  Using a sychronous get
   call to avoid race conditions.

During the following scenario, the DWC3 runtime suspend routine is blocked as
the connected flag is still true:

1.  Enumerate device w/ host.
2.  Gadget is unbinded
- echo "" > /sys/kernel/config/usb_gadget/g1/UDC
3.  Disconnect the USB cable (VBUS low)
4.  No dwc3_gadget_disconnect_interrupt() seen (since controller is
   halted from step#1)
5.  Runtime PM autosuspend fails due to "dwc->connected" being true
(cleared in dwc3_gadget_disconnect_interrupt())
6.  Gadget binded
- echo udc_name > /sys/kernel/config/usb_gadget/g1/UDC
7.  No runtime suspend until cable is plugged in and out

Technically, for device initiated disconnects, there is no active session/link
with the host, so the DWC3 controller should be allowed to go into a low power
state.  Also, we need to now consider when re-binding the UDC,
dwc3_gadget_set_speed() is executed before dwc3_gadget_pullup(), so if the DWC3
controller is suspended/disabled, while accessing the DCFG, that could result in
bus timeouts, etc...  Change the dwc3_gadget_set_speed() to save the speed
being requested, and program it during dwc3_gadget_run_stop(), which is executed
during PM runtime resume.  If not, previous setting will be overridden as we
execute a DWC3 controller reset during PM runtime resume. 

Wesley Cheng (2):
  usb: dwc3: gadget: Allow runtime suspend if UDC unbinded
  usb: dwc3: gadget: Preserve UDC max speed setting

 drivers/usb/dwc3/core.h   |   1 +
 drivers/usb/dwc3/gadget.c | 121 ++
 2 files changed, 71 insertions(+), 51 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[jira] [Commented] (SPARK-33359) foreachBatch sink outputs wrong metrics

[John Wesley (Jira)]

[ 
https://issues.apache.org/jira/browse/SPARK-33359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17227064#comment-17227064
 ] 

John Wesley commented on SPARK-33359:
-

Thanks for the clarification. How about numInputRows?

> foreachBatch sink outputs wrong metrics
> ---
>
> Key: SPARK-33359
> URL: https://issues.apache.org/jira/browse/SPARK-33359
> Project: Spark
>  Issue Type: Bug
>  Components: Structured Streaming
>Affects Versions: 3.0.0
> Environment: Spark on Kubernetes cluster with spark-3.0.0 image. The 
> CRD is ScheduledSparkApplication
>Reporter: John Wesley
>Priority: Minor
>
> I created 2 similar jobs, 
> 1) First job reading from kafka and writing to console sink in append mode
> 2) Second job reading from kafka and writing to foreachBatch sink (which then 
> writes in parquet format to S3).
> The metrics in the log for console shows correct values for numInputRows and 
> numOutputRows whereas they are wrong for foreachBatch.
> With foreachBatch:
> numInputRows is +1 more than what is actually present
> numOutputRows is always -1.
> ///Console sink
> //20/11/05 13:36:21 INFO 
> MicroBatchExecution: Streaming query made progress: {
>   "id" : "775aa543-58bf-4cf7-b274-390da640b6ae",
>   "runId" : "e5eac4ca-0b29-4ed4-be35-b70bd20906d5",
>   "name" : null,
>   "timestamp" : "2020-11-05T13:36:08.921Z",
>   "batchId" : 0,
>   "numInputRows" : 10,
>   "processedRowsPerSecond" : 0.7759757895553658,
>   "durationMs" : {
> "addBatch" : 7735,
> "getBatch" : 152,
> "latestOffset" : 2037,
> "queryPlanning" : 1010,
> "triggerExecution" : 12886,
> "walCommit" : 938
>   },
>   "stateOperators" : [ ],
>   "sources" : [ {
> "description" : "KafkaV2[Subscribe[testedr7]]",
> "startOffset" : null,
> "endOffset" : {
>   "testedr7" : {
> "0" : 10
>   }
> },
> "numInputRows" : 10,
> "processedRowsPerSecond" : 0.7759757895553658
>   } ],
>   "sink" : {
> "description" : 
> "org.apache.spark.sql.execution.streaming.ConsoleTable$@38c3a814",
> "numOutputRows" : 10
>   }
> }
> ///ForEachBatch Sink
> //20/11/05 13:43:38 INFO 
> MicroBatchExecution: Streaming query made progress: {
>   "id" : "789f9a00-2f2a-4f75-b643-fea201088b4a",
>   "runId" : "b5e695c5-3a2e-4ad2-9dbf-11b69f368f61",
>   "name" : null,
>   "timestamp" : "2020-11-05T13:43:15.421Z",
>   "batchId" : 0,
>   "numInputRows" : 11,
>   "processedRowsPerSecond" : 0.4833252779120348,
>   "durationMs" : {
> "addBatch" : 17689,
> "getBatch" : 135,
> "latestOffset" : 2121,
> "queryPlanning" : 880,
> "triggerExecution" : 22758,
> "walCommit" : 876
>   },
>   "stateOperators" : [ ],
>   "sources" : [ {
> "description" : "KafkaV2[Subscribe[testedr7]]",
> "startOffset" : null,
> "endOffset" : {
>   "testedr7" : {
> "0" : 10
>   }
> },
> "numInputRows" : 11,
> "processedRowsPerSecond" : 0.4833252779120348
>   } ],
>   "sink" : {
> "description" : "ForeachBatchSink",
> "numOutputRows" : -1
>   }
> }



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Created] (SPARK-33361) Dataset.observe() functionality does not work with structured streaming

[John Wesley (Jira)]

John Wesley created SPARK-33361:
---

 Summary: Dataset.observe() functionality does not work with 
structured streaming
 Key: SPARK-33361
 URL: https://issues.apache.org/jira/browse/SPARK-33361
 Project: Spark
  Issue Type: Bug
  Components: Structured Streaming
Affects Versions: 3.0.0
 Environment: Spark on k8s, version 3.0.0
Reporter: John Wesley


The dataset observe() functionality does not work as expected with spark in 
cluster mode.
Related discussion here:
[http://apache-spark-user-list.1001560.n3.nabble.com/Best-way-to-emit-custom-metrics-to-Prometheus-in-spark-structured-streaming-td38826.html]

Using lit() as the aggregation column goes through well. However sum, count etc 
returns 0 all the time.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Created] (SPARK-33359) foreachBatch sink outputs wrong metrics

[John Wesley (Jira)]

John Wesley created SPARK-33359:
---

 Summary: foreachBatch sink outputs wrong metrics
 Key: SPARK-33359
 URL: https://issues.apache.org/jira/browse/SPARK-33359
 Project: Spark
  Issue Type: Bug
  Components: Structured Streaming
Affects Versions: 3.0.0
 Environment: Spark on Kubernetes cluster with spark-3.0.0 image. The 
CRD is ScheduledSparkApplication
Reporter: John Wesley


I created 2 similar jobs, 
1) First job reading from kafka and writing to console sink in append mode
2) Second job reading from kafka and writing to foreachBatch sink (which then 
writes in parquet format to S3).

The metrics in the log for console shows correct values for numInputRows and 
numOutputRows whereas they are wrong for foreachBatch.

With foreachBatch:
numInputRows is +1 more than what is actually present

numOutputRows is always -1.
///Console sink
//20/11/05 13:36:21 INFO 
MicroBatchExecution: Streaming query made progress: {
  "id" : "775aa543-58bf-4cf7-b274-390da640b6ae",
  "runId" : "e5eac4ca-0b29-4ed4-be35-b70bd20906d5",
  "name" : null,
  "timestamp" : "2020-11-05T13:36:08.921Z",
  "batchId" : 0,
  "numInputRows" : 10,
  "processedRowsPerSecond" : 0.7759757895553658,
  "durationMs" : {
"addBatch" : 7735,
"getBatch" : 152,
"latestOffset" : 2037,
"queryPlanning" : 1010,
"triggerExecution" : 12886,
"walCommit" : 938
  },
  "stateOperators" : [ ],
  "sources" : [ {
"description" : "KafkaV2[Subscribe[testedr7]]",
"startOffset" : null,
"endOffset" : {
  "testedr7" : {
"0" : 10
  }
},
"numInputRows" : 10,
"processedRowsPerSecond" : 0.7759757895553658
  } ],
  "sink" : {
"description" : 
"org.apache.spark.sql.execution.streaming.ConsoleTable$@38c3a814",
"numOutputRows" : 10
  }
}


///ForEachBatch Sink
//20/11/05 13:43:38 INFO 
MicroBatchExecution: Streaming query made progress: {
  "id" : "789f9a00-2f2a-4f75-b643-fea201088b4a",
  "runId" : "b5e695c5-3a2e-4ad2-9dbf-11b69f368f61",
  "name" : null,
  "timestamp" : "2020-11-05T13:43:15.421Z",
  "batchId" : 0,
  "numInputRows" : 11,
  "processedRowsPerSecond" : 0.4833252779120348,
  "durationMs" : {
"addBatch" : 17689,
"getBatch" : 135,
"latestOffset" : 2121,
"queryPlanning" : 880,
"triggerExecution" : 22758,
"walCommit" : 876
  },
  "stateOperators" : [ ],
  "sources" : [ {
"description" : "KafkaV2[Subscribe[testedr7]]",
"startOffset" : null,
"endOffset" : {
  "testedr7" : {
"0" : 10
  }
},
"numInputRows" : 11,
"processedRowsPerSecond" : 0.4833252779120348
  } ],
  "sink" : {
"description" : "ForeachBatchSink",
"numOutputRows" : -1
  }
}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Re: [PATCH 1/2] usb: dwc3: gadget: Allow runtime suspend if UDC unbinded

[Wesley Cheng]

On 11/3/2020 12:07 PM, Alan Stern wrote:
> On Tue, Nov 03, 2020 at 11:02:25AM -0800, Wesley Cheng wrote:
>>
>>
>> On 10/28/2020 6:07 PM, Alan Stern wrote:
>>>> --- a/drivers/usb/dwc3/gadget.c
>>>> +++ b/drivers/usb/dwc3/gadget.c
>>>> @@ -1995,6 +1995,11 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
>>>> int is_on)
>>>>unsigned long   flags;
>>>>int ret;
>>>>  
>>>> +  if (pm_runtime_suspended(dwc->dev)) {
>>>> +  pm_request_resume(dwc->dev);
>>>> +  return 0;
>>>> +  }
>>>
>>> Isn't this racy?  What happens if the controller was active but a 
>>> runtime suspend occurs right here?
>>>
>>> Alan Stern
>>>
>>
>> Hi Alan,
>>
>> Ah, yes you're right.  I was hoping that the PM runtime layer would be
>> utilizing the spinlock when reading out the runtime status, but even
>> then, we wouldn't be able to catch intermediate states with this API
>> (i.e. RPM_RESUMING or RPM_SUSPENDING)
>>
>> Tried a few different approaches, and came up with something like the
>> following:
>>
>> static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
>> {
>> ...
>>  ret = pm_runtime_get_sync(dwc->dev);
>>  if (!ret) {
>>  pm_runtime_put(dwc->dev);
>>  return 0;
>>  }
>>  ...
>>  pm_runtime_put(dwc->dev);
>>
>>  return 0;
>> }
>>
>> I think this should be good to address your concern.  The only way we
>> would be able to ensure that the runtime PM state doesn't enter
>> idle/suspend is if we increment the usage count for the duration we're
>> accessing the DWC3 registers.  With the synchronous PM runtime resume
>> call, we can also ensure that no pending runtime suspends are executing
>> in parallel while running this code.
> 
> That's correct.
> 
>> The check for the zero return value would be for avoiding running the
>> DWC3 run stop sequence for the case where we executed the runtime PM
>> resume, as the DWC3 runtime PM resume routine will set the run stop bit
>> in there.
> 
> If you need to add an explanation of this subtle point in your email 
> message, then you should add a similar explanation as a comment in the 
> code.  And don't forget to check for ret < 0 (i.e., a resume error).
> 

Hi Alan,

Got it, will do.  Yes, I'll include the error conditions as well in the
actual change.  Thanks again!

Thanks

Regards,
Wesley Cheng

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] usb: dwc3: gadget: Allow runtime suspend if UDC unbinded

[Wesley Cheng]

On 10/28/2020 6:07 PM, Alan Stern wrote:
> On Wed, Oct 28, 2020 at 04:43:10PM -0700, Wesley Cheng wrote:
>> The DWC3 runtime suspend routine checks for the USB connected parameter to
>> determine if the controller can enter into a low power state.  The
>> connected state is only set to false after receiving a disconnect event.
>> However, in the case of a device initiated disconnect (i.e. UDC unbind),
>> the controller is halted and a disconnect event is never generated.  Set
>> the connected flag to false if issuing a device initiated disconnect to
>> allow the controller to be suspended.
>>
>> Signed-off-by: Wesley Cheng 
>> ---
>>  drivers/usb/dwc3/gadget.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 5d879b7606d5..6364429b2122 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1995,6 +1995,11 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
>> int is_on)
>>  unsigned long   flags;
>>  int ret;
>>  
>> +if (pm_runtime_suspended(dwc->dev)) {
>> +pm_request_resume(dwc->dev);
>> +return 0;
>> +}
> 
> Isn't this racy?  What happens if the controller was active but a 
> runtime suspend occurs right here?
> 
> Alan Stern
> 

Hi Alan,

Ah, yes you're right.  I was hoping that the PM runtime layer would be
utilizing the spinlock when reading out the runtime status, but even
then, we wouldn't be able to catch intermediate states with this API
(i.e. RPM_RESUMING or RPM_SUSPENDING)

Tried a few different approaches, and came up with something like the
following:

static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
{
...
ret = pm_runtime_get_sync(dwc->dev);
if (!ret) {
pm_runtime_put(dwc->dev);
return 0;
}
...
pm_runtime_put(dwc->dev);

return 0;
}

I think this should be good to address your concern.  The only way we
would be able to ensure that the runtime PM state doesn't enter
idle/suspend is if we increment the usage count for the duration we're
accessing the DWC3 registers.  With the synchronous PM runtime resume
call, we can also ensure that no pending runtime suspends are executing
in parallel while running this code.

The check for the zero return value would be for avoiding running the
DWC3 run stop sequence for the case where we executed the runtime PM
resume, as the DWC3 runtime PM resume routine will set the run stop bit
in there.

Thanks

Regards,
Wesley Cheng
>> +
>>  is_on = !!is_on;
>>  
>>  /*
>> @@ -2050,6 +2055,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
>> int is_on)
>>  dwc->ev_buf->lpos = (dwc->ev_buf->lpos + count) %
>>  dwc->ev_buf->length;
>>  }
>> +dwc->connected = false;
>>  }
>>  
>>  ret = dwc3_gadget_run_stop(dwc, is_on, false);
>> -- 
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[ovirt-users] Re: oVirt 4.3.10 RHEL 7.9 support

[Wesley Stewart]

In pretty sure all of 4.3 is compatible with RHEL7 and Centos7.

I haven't tried the specific versions myself though.

On Thu, Oct 29, 2020, 7:37 AM KSNull Zero  wrote:

> Anyone ?
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/YPLSVYRVGHHEBD2OZG6VGT5ES2ZQNDQ4/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/O5JCLAONOFGYCZVF6EQU5JCVQPVAXH24/

RE: Heath check responds up even when server is down

[Wesley Lukehart]

r 
implementation. So I don't think the issue I am having is attributable to any 
particular version of haproxy.

Does anyone have any ideas on how I can get haproxy to recognize when Exchange 
is in maintenance mode?

Its baffling to me how the health check can pass and get a 200 response when 
the page isn't accessible by any other means (browsers, wget).
It seems haproxy's health check requests are fundamentally different than a 
regular browser request and that this what is driving the difference in 
response.

Hopefully there is a way to configure haproxy to request a health check in such 
a way that an Exchange service in maintenance mode is properly detected as down.

Thanks,

-Luke

From: Wesley Lukehart
Sent: Wednesday, October 14, 2020 18:28
To: 'haproxy@formilux.org' 
Subject: Heath check responds up even when server is down

Hello fine people. Short time lurker, first time poster.

Was on version 2.0.5 with CentOS 7.6 and everything was working fine with 
Exchange 2019.
Upgraded to 2.2.3 and now when we put Exchange into maintenance mode HAProxy 
does not change status - it reports that all services are still up (L7OK/200).

Example backend:
backend be_ex2019_oab
  mode http
  balance roundrobin
  option httpchk GET /oab/healthcheck.htm
  option log-health-checks
  http-check expect status 200
  server  :443 check ssl inter 15s verify required 
ca-file 
  server  :443 check ssl inter 15s verify required 
ca-file 

If I stop the app pool for a service in IIS, or stop all of IIS, HAProxy will 
properly show the service/services as down - as it gets a non 200 response (503 
or 404).

When putting the Exchange server into maintenance mode, there is no http 
response.
When I check with a browser I get "ERR_HTTP2_PROTOCOL_ERROR" or "Secure 
Connection Failed". Basically no response.
When I check with wget from the haproxy server I get "HTTP request sent, 
awaiting response... Read error (Connection reset by peer) in headers."
Yet HAProxy is happy and continues to try to send mail to the down server - not 
good.

Any Ideas?

I just tried 2.2.4 and no joy.

Thanks,

-Luke

Re: [PATCH 2/2] usb: dwc3: gadget: Preserve UDC max speed setting

[Wesley Cheng]

On 10/28/2020 5:43 PM, Thinh Nguyen wrote:
> Hi,
> 
> Wesley Cheng wrote:
>> The USB gadget/UDC driver can restrict the DWC3 controller speed using
>> dwc3_gadget_set_speed().  Store this setting into a variable, in order for
>> this setting to persist across controller resets due to runtime PM.
> 
> Why do we need to do this? DCFG should persist unless we overwrite it.
> The current PM shouldn't update the current speed setting.
> 
> BR,
> Thinh
> 

Hi Thinh,

During runtime PM suspend, the dwc3_suspend_common() will call
dwc3_core_exit().  On some platforms they register the DWC3 reset
control to the DWC3 core driver (otherwise could be handled in the DWC3
glue drivers), which will be asserted here:

static void dwc3_core_exit(struct dwc3 *dwc)
{
...
reset_control_assert(dwc->reset);

>From the SNPS databook (Table 2-2 Resets for Registers) it mentions that
assertion of the reset signal will reset the DCFG register.

In addition to the above, with the change to allow runtime PM suspend
during UDC unbind, we need a way to avoid writing to the DCFG during the
UDC bind path. (if we entered suspend before re-binding the UDC)  If we
add an early exit based on the PM state (in
dwc3_gadget_set_udc_speed()), then we basically ignore the max speed
request from the UDC/gadget layer.

Since it looks like the DWC3 gadget driver doesn't like using
synchronous PM runtime resumes, by going this route, we can allow the
async runtime resume handler to do everything, such as writing the speed
config and re-enabling the controller.

Thanks

Regards,
Wesley Cheng
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/2] usb: dwc3: gadget: Allow runtime suspend if UDC unbinded

[Wesley Cheng]

The DWC3 runtime suspend routine checks for the USB connected parameter to
determine if the controller can enter into a low power state.  The
connected state is only set to false after receiving a disconnect event.
However, in the case of a device initiated disconnect (i.e. UDC unbind),
the controller is halted and a disconnect event is never generated.  Set
the connected flag to false if issuing a device initiated disconnect to
allow the controller to be suspended.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/gadget.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 5d879b7606d5..6364429b2122 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1995,6 +1995,11 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
unsigned long   flags;
int ret;
 
+   if (pm_runtime_suspended(dwc->dev)) {
+   pm_request_resume(dwc->dev);
+   return 0;
+   }
+
is_on = !!is_on;
 
/*
@@ -2050,6 +2055,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
dwc->ev_buf->lpos = (dwc->ev_buf->lpos + count) %
dwc->ev_buf->length;
}
+   dwc->connected = false;
}
 
ret = dwc3_gadget_run_stop(dwc, is_on, false);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/2] Allow DWC3 runtime suspend if UDC is unbinded

[Wesley Cheng]

During the following scenario, the DWC3 runtime suspend routine is blocked as
the connected flag is still true:

1.  Enumerate device w/ host.
2.  Gadget is unbinded
- echo "" > /sys/kernel/config/usb_gadget/g1/UDC
3.  Disconnect the USB cable (VBUS low)
4.  No dwc3_gadget_disconnect_interrupt() seen (since controller is
   halted from step#1)
5.  Runtime PM autosuspend fails due to "dwc->connected" being true
(cleared in dwc3_gadget_disconnect_interrupt())
6.  Gadget binded
- echo udc_name > /sys/kernel/config/usb_gadget/g1/UDC
7.  No runtime suspend until cable is plugged in and out

Technically, for device initiated disconnects, there is no active session/link
with the host, so the DWC3 controller should be allowed to go into a low power
state.  Also, we need to now consider when re-binding the UDC,
dwc3_gadget_set_speed() is executed before dwc3_gadget_pullup(), so if the DWC3
controller is suspended/disabled, while accessing the DCFG, that could result in
bus timeouts, etc...  Change the dwc3_gadget_set_speed() to save the speed
being requested, and program it during dwc3_gadget_run_stop(), which is executed
during PM runtime resume.  If not, previous setting will be overridden as we
execute a DWC3 controller reset during PM runtime resume. 

Wesley Cheng (2):
  usb: dwc3: gadget: Allow runtime suspend if UDC unbinded
  usb: dwc3: gadget: Preserve UDC max speed setting

 drivers/usb/dwc3/core.h   |   1 +
 drivers/usb/dwc3/gadget.c | 114 +-
 2 files changed, 64 insertions(+), 51 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/2] usb: dwc3: gadget: Preserve UDC max speed setting

[Wesley Cheng]

The USB gadget/UDC driver can restrict the DWC3 controller speed using
dwc3_gadget_set_speed().  Store this setting into a variable, in order for
this setting to persist across controller resets due to runtime PM.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/core.h   |   1 +
 drivers/usb/dwc3/gadget.c | 108 --
 2 files changed, 58 insertions(+), 51 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 2f04b3e42bf1..390d3deef0ba 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1119,6 +1119,7 @@ struct dwc3 {
u32 nr_scratch;
u32 u1u2;
u32 maximum_speed;
+   u32 gadget_max_speed;
 
u32 ip;
 
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 6364429b2122..1a93b92a5e6f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1941,6 +1941,61 @@ static void dwc3_stop_active_transfers(struct dwc3 *dwc)
}
 }
 
+static void __dwc3_gadget_set_speed(struct dwc3 *dwc)
+{
+   u32 reg;
+
+   reg = dwc3_readl(dwc->regs, DWC3_DCFG);
+   reg &= ~(DWC3_DCFG_SPEED_MASK);
+
+   /*
+* WORKAROUND: DWC3 revision < 2.20a have an issue
+* which would cause metastability state on Run/Stop
+* bit if we try to force the IP to USB2-only mode.
+*
+* Because of that, we cannot configure the IP to any
+* speed other than the SuperSpeed
+*
+* Refers to:
+*
+* STAR#9000525659: Clock Domain Crossing on DCTL in
+* USB 2.0 Mode
+*/
+   if (DWC3_VER_IS_PRIOR(DWC3, 220A) &&
+   !dwc->dis_metastability_quirk) {
+   reg |= DWC3_DCFG_SUPERSPEED;
+   } else {
+   switch (dwc->gadget_max_speed) {
+   case USB_SPEED_LOW:
+   reg |= DWC3_DCFG_LOWSPEED;
+   break;
+   case USB_SPEED_FULL:
+   reg |= DWC3_DCFG_FULLSPEED;
+   break;
+   case USB_SPEED_HIGH:
+   reg |= DWC3_DCFG_HIGHSPEED;
+   break;
+   case USB_SPEED_SUPER:
+   reg |= DWC3_DCFG_SUPERSPEED;
+   break;
+   case USB_SPEED_SUPER_PLUS:
+   if (DWC3_IP_IS(DWC3))
+   reg |= DWC3_DCFG_SUPERSPEED;
+   else
+   reg |= DWC3_DCFG_SUPERSPEED_PLUS;
+   break;
+   default:
+   dev_err(dwc->dev, "invalid speed (%d)\n", 
dwc->gadget_max_speed);
+
+   if (DWC3_IP_IS(DWC3))
+   reg |= DWC3_DCFG_SUPERSPEED;
+   else
+   reg |= DWC3_DCFG_SUPERSPEED_PLUS;
+   }
+   }
+   dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+}
+
 static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
 {
u32 reg;
@@ -1963,6 +2018,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int 
is_on, int suspend)
if (dwc->has_hibernation)
reg |= DWC3_DCTL_KEEP_CONNECT;
 
+   __dwc3_gadget_set_speed(dwc);
dwc->pullups_connected = true;
} else {
reg &= ~DWC3_DCTL_RUN_STOP;
@@ -2318,59 +2374,9 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g,
 {
struct dwc3 *dwc = gadget_to_dwc(g);
unsigned long   flags;
-   u32 reg;
 
spin_lock_irqsave(>lock, flags);
-   reg = dwc3_readl(dwc->regs, DWC3_DCFG);
-   reg &= ~(DWC3_DCFG_SPEED_MASK);
-
-   /*
-* WORKAROUND: DWC3 revision < 2.20a have an issue
-* which would cause metastability state on Run/Stop
-* bit if we try to force the IP to USB2-only mode.
-*
-* Because of that, we cannot configure the IP to any
-* speed other than the SuperSpeed
-*
-* Refers to:
-*
-* STAR#9000525659: Clock Domain Crossing on DCTL in
-* USB 2.0 Mode
-*/
-   if (DWC3_VER_IS_PRIOR(DWC3, 220A) &&
-   !dwc->dis_metastability_quirk) {
-   reg |= DWC3_DCFG_SUPERSPEED;
-   } else {
-   switch (speed) {
-   case USB_SPEED_LOW:
-   reg |= DWC3_DCFG_LOWSPEED;
-   break;
-   case USB_SPEED_FULL:
-   reg |= DWC3_DCFG_FULLSPEED;
-   break;
-   case USB_SPEED_HIGH:
-   reg |= DWC3_DCFG_HIGHSPEED;
-   break;
-   

Re: [google-appengine] Google App Engine code not updated after deployment

[wesley chun]

Go to your app's Services page
<https://console.cloud.google.com/appengine/services>. You should then see
what's up-and-running. For each live version, if you go to the Diagnose
column and click on the Tools pulldown, select "Source" to see the files so
you can see the code that's running under specific versions and confirm
what's running (and what's not).

On Wed, Oct 28, 2020 at 1:10 AM Tuan Nguyen  wrote:

> Hi,
> So I have a GAE app. However when I update the application multiple times
> a day, sometimes the website is reverted back to the previous version, or
> just does not contain the latest code.
> Just wondering how to fix this behaviour. I have deleted all unused
> versions, but seems like the code is not at the latest when I do a
> deployment.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/95f60db1-c6f4-4c9d-ab9a-16da049d3c5dn%40googlegroups.com
> <https://groups.google.com/d/msgid/google-appengine/95f60db1-c6f4-4c9d-ab9a-16da049d3c5dn%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
wesley chun :: @wescpy <http://twitter.com/wescpy> :: Software
Architect & Engineer
Developer Advocate at Google Cloud by day; at night...
Python training & consulting : http://CyberwebConsulting.com
"Core Python" books : http://CorePython.com
Python blog: http://wescpy.blogspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAB6eaA4MfOBi1akKE9q%2B2F_qqDAyPNBbdJNgaU1ztOX94t1d6w%40mail.gmail.com.

[ovirt-users] Re: Migrated disk from NFS to iSCSI - Unable to Boot

[Wesley Stewart]

I think I figured this one out.  Looks like the disk format changed when
moving to block storage.  The VM template could not cope with this change.
I deleted the VM, and attached the disk to a new VM, and everything worked
fine.


On Tue, Oct 27, 2020 at 8:41 AM Wesley Stewart  wrote:

> This is a new one.
>
> I migrated from an NFS share to an iSCSI share on a small single node
> oVirt system (Currently running 4.3.10).
>
> After migrating a disk (Virtual Machine -> Disk -> Move), I was unable to
> boot to it.  The console tells me "No bootable device".  This is a Centos7
> guest.
>
> I booted into a CentOS7 ISO and tried a few things...
>
> fdisk -l shows me a 40GB disk (/dev/sda).
> fsck -f tells me "bad magic number in superblock"
>
> lvdisplay and pvdisplay show nothing.  Even if I can't boot to the drive I
> would love to recover a couple of documents from here if possible.  Does
> anyone have any suggestions?  I am running out of ideas.
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PW26DIBGKOJZM7PWACLBTF37TQLNJFBG/

[Mpi-forum] Errata Announcement for December Meeting / MPI 4.0 RC

[Wesley Bland via mpi-forum]

Hi all,

I’d like to announce the following issue/PR for inclusion in the MPI 4.0 RC and 
voting at the December meeting:

Error: Section 12.4.3 - p. 515 - MPI_INIT argc/argv values
Issue - https://github.com/mpi-forum/mpi-issues/issues/168 

PR - https://github.com/mpi-forum/mpi-standard/pull/182 
 

This is the issue I read last week in the virtual meeting which copies the text 
about how to handle argc/argv in MPI_INIT_THREAD.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[ovirt-users] Migrated disk from NFS to iSCSI - Unable to Boot

[Wesley Stewart]

This is a new one.

I migrated from an NFS share to an iSCSI share on a small single node oVirt
system (Currently running 4.3.10).

After migrating a disk (Virtual Machine -> Disk -> Move), I was unable to
boot to it.  The console tells me "No bootable device".  This is a Centos7
guest.

I booted into a CentOS7 ISO and tried a few things...

fdisk -l shows me a 40GB disk (/dev/sda).
fsck -f tells me "bad magic number in superblock"

lvdisplay and pvdisplay show nothing.  Even if I can't boot to the drive I
would love to recover a couple of documents from here if possible.  Does
anyone have any suggestions?  I am running out of ideas.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/53HYTD32FP62FVALY6E5NNEDYG2XYOS5/

Re: [Emc-users] Cutting fluid

[Sven Wesley]

Many moons ago, but sure we did experience some bad allergy reactions from
cutting fluid. Some fluids are prone bacteria growth and if the system
isn't cleaned regularly you may end up with a biohazard de luxe.
Don't ask me how I know, but the sanitation of 25 machines sized workshop
took a while

Den tors 22 okt. 2020 kl 20:25 skrev Nicklas SB Karlsson :

> In some oils there are PAHs polyaromatic hydrocarbons and these have
> been linked to some forms of cancer
> https://en.wikipedia.org/wiki/Polycyclic_aromatic_hydrocarbon Then
> reading about Creosot https://en.wikipedia.org/wiki/Creosote I found
> there is difference in chemical properties between coal-tar and wood-tar
> Creosot and I also expect difference in chemical properties between
> mineral oil and vegetable oil.
>
> Expect food oil to be relatively harmless also then used as a cutting
> fluid, no rust and does not freeze during winter. Maybe bacterial growth
> might be a problem but in such case I could kill them by heating
> regularly. Do not freeze during winter is an important future for me as
> is now.
>
>
> Den 2020-10-21 kl. 21:44, skrev marcus.bow...@visible.eclipse.co.uk:
> > On 2020-10-21 20:10, Nicklas SB Karlsson wrote:
> >> I learned cutting fluid could be unhealthy. Anyone here have any
> >> experience?
> >>
> > I understand the problem has been that soluble cutting oil tends to
> > drench the operator at waist level (on older machines which do not
> > have total enclosures). That led to a noted connection between cancer
> > and soluble oil.
> > I don't know of any link between neat cutting oil and medical
> > conditions, but it is an oil, so the usual hazards apply.
> >
> > I have serious reservations about the current fashion for atomised
> > mist spray coolant, which I believe to be a real danger to the lungs
> > and possibly the eyes, nose and mouth. I have not seen any medical
> > studies on this, but atomised fluids of all sorts are generally a bad
> > idea.
> > Just my opinion.
> >
> > Marcus
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[go-cd] GoCD with Bitbucket Cloud Issue

[Wesley Sonner]

I hope this is the right forum, please forgive me if it isn't. We use GoCD 
for our CI/CD with git on Bitbucket cloud. Recently some brilliant dude 
(me) removed the user in BB whose user and SSH keys were being used to run 
all the git commands against our BB repo. So now nothing works. We're 
looking for advice for reinstating a working SSH key and user to get our 
builds working again.  Any advice would be so appreciated. 

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/ada3a03f-1a1b-4e29-9081-ead4b4c344e1n%40googlegroups.com.

[Mpi-forum] MPI Forum Virtual Meeting Tomorrow

[Wesley Bland via mpi-forum]

Hi all,

I just wanted to remind everyone to be updating the status of any issues/pull 
requests being worked on for MPI 4.0 on the project board 
(https://github.com/mpi-forum/mpi-issues/projects/2 
). Tomorrow we have a 
virtual meeting to get updates on anything that needs to be discussed there. A 
few folks have told me that they would like to go ahead with some unofficial 
readings for those items so we can move them forward for the release candidate 
coming out in a few weeks.

Please remember that we need to have everything that has already been voted 
into MPI 4.0 merged into the mpi-4.x branch by the end of the month so we can 
start merging the remaining errata and other fixes into the release candidate 
branch immediately after that to be able to generate the release candidate for 
us to review and release at SC20.

See you tomorrow.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Geoserver-users] Using the ImageMosaic plugin for raster with time and elevation data

[wesley mezine]

The administrator can you remove my attachments, please ?

Em seg, 19 de out de 2020 16:42, Alexander Petkov 
escreveu:

> The problem is evident right here:
> ===
> Caused by: org.postgresql.util.PSQLException: FATAL: password
> authentication failed for user "wandersen"
> at
> org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:514)
> at
> org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:141)
> at
> org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:192)
> at
> org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49)
> at org.postgresql.jdbc.PgConnection.(PgConnection.java:195)
> at org.postgresql.Driver.makeConnection(Driver.java:454)
> at org.postgresql.Driver.connect(Driver.java:256)
> 
>
> The password in datastore.properties needs to be corrected
>
>
> On Mon, Oct 19, 2020 at 5:05 AM wesley mezine 
> wrote:
>
>> Good Morning,
>>
>> I am sending attached the log files and the files used to create the
>> mosaic image.
>>
>> Regards,
>>
>> Wesley
>>
>> Em sáb., 17 de out. de 2020 às 16:47, Alexander Petkov <
>> green...@gmail.com> escreveu:
>>
>>> We need the rest of the log trace.
>>>
>>>
>>> On 10/11/20, wmezine  wrote:
>>> > Hi,
>>> >
>>> > I followed all the steps in the tutorial to create a time series of
>>> images,
>>> > according to the tutorial:
>>> >
>>> >
>>> https://docs.geoserver.org/latest/en/user/tutorials/imagemosaic_timeseries/imagemosaic_timeseries.html
>>> > <
>>> https://docs.geoserver.org/latest/en/user/tutorials/imagemosaic_timeseries/imagemosaic_timeseries.html
>>> >
>>> >
>>> >
>>> > I can do it by generating the shapefile, but when I do it with
>>> > data.properties to connect to Postgis, the following error occurs:
>>> >
>>> > /Could not list layers for this store, an error occurred retrieving
>>> them:
>>> > Failed to create reader from file:data/mosaico and hints Hints:
>>> REPOSITORY
>>> > =
>>> > org.geoserver.catalog.CatalogRepository@915b19 EXECUTOR_SERVICE =
>>> > java.util.concurrent.ThreadPoolExecutor@1460d69[Running, pool size =
>>> 0,
>>> > active threads = 0, queued tasks = 0, completed tasks = 0] System
>>> defaults:
>>> > GRID_COVERAGE_FACTORY = GridCoverageFactory TILE_ENCODING = null
>>> > FEATURE_FACTORY =
>>> org.geotools.feature.LenientFeatureFactoryImpl@1e7efef
>>> > FORCE_AXIS_ORDER_HONORING = http FORCE_LONGITUDE_FIRST_AXIS_ORDER =
>>> true
>>> > FILTER_FACTORY = FilterFactoryImpl LENIENT_DATUM_SHIFT = true
>>> > COMPARISON_TOLERANCE = 1.0E-8 STYLE_FACTORY = StyleFactoryImpl/
>>> >
>>> > Can someone help me, please ?
>>> >
>>> > Regards,
>>> >
>>> > Wesley
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Sent from:
>>> http://osgeo-org.1560.x6.nabble.com/GeoServer-User-f3786390.html
>>> >
>>> >
>>> > ___
>>> > Geoserver-users mailing list
>>> >
>>> > Please make sure you read the following two resources before posting
>>> to this
>>> > list:
>>> > - Earning your support instead of buying it, but Ian Turton:
>>> > http://www.ianturton.com/talks/foss4g.html#/
>>> > - The GeoServer user list posting guidelines:
>>> > http://geoserver.org/comm/userlist-guidelines.html
>>> >
>>> > If you want to request a feature or an improvement, also see this:
>>> >
>>> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>>> >
>>> >
>>> > Geoserver-users@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>> >
>>>
>>
___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[cobirds] White throated sparrow

[Jace Wesley Brasher]

Hello,
Again I am looking for advice on where to find a bird. The white throated
sparrow is one of my favorite birds and I have gotten to spend lots of time
with them in the past couple years. I am looking for somewhere where I can
find them near loveland or fort Collins, and wondering where people have
had the best luck for this species?

Thanks
Jace Brasher
Loveland
Larimer county

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTygW-GcxHeYTgj_rG%2BUovhsqu4VY2635Fj%3DPHxUE6tZD0A%40mail.gmail.com.

Bug#972293: linux-image-5.8.0-1-amd64: kernel seems to break pulseaudio HDMI sound

[Wesley Schwengle]

On 2020-10-15 19:13, Wesley Schwengle wrote:


When booting with the linux-image-5.8.0-2-amd64 kernel I don't have
sound on my HDMI output. The pulseaudio config hasn't changed yet it
suddenly stopped working after a reboot.

When booting linux-image-5.8.0-1-amd64, the whole setup works again
without fail.

linux-image-5.8.0-1-amd64:
   Installed: 5.8.7-1
   Candidate: 5.8.7-1
   Version table:
  *** 5.8.7-1 100
 100 /var/lib/dpkg/status

linux-image-5.8.0-2-amd64:
   Installed: 5.8.10-1
   Candidate: 5.8.10-1
   Version table:
  *** 5.8.10-1 500
 500 http://deb.debian.org/debian testing/main amd64 Packages
 100 /var/lib/dpkg/status



The issue seems to be fixed in sid:

linux-image-5.8.0-3-amd64:
  Installed: 5.8.14-1
  Candidate: 5.8.14-1
  Version table:
 *** 5.8.14-1 300
300 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

This works

Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

Bug#972293: linux-image-5.8.0-1-amd64: kernel seems to break pulseaudio HDMI sound

[Wesley Schwengle]

On 2020-10-15 19:13, Wesley Schwengle wrote:


When booting with the linux-image-5.8.0-2-amd64 kernel I don't have
sound on my HDMI output. The pulseaudio config hasn't changed yet it
suddenly stopped working after a reboot.

When booting linux-image-5.8.0-1-amd64, the whole setup works again
without fail.

linux-image-5.8.0-1-amd64:
   Installed: 5.8.7-1
   Candidate: 5.8.7-1
   Version table:
  *** 5.8.7-1 100
 100 /var/lib/dpkg/status

linux-image-5.8.0-2-amd64:
   Installed: 5.8.10-1
   Candidate: 5.8.10-1
   Version table:
  *** 5.8.10-1 500
 500 http://deb.debian.org/debian testing/main amd64 Packages
 100 /var/lib/dpkg/status



The issue seems to be fixed in sid:

linux-image-5.8.0-3-amd64:
  Installed: 5.8.14-1
  Candidate: 5.8.14-1
  Version table:
 *** 5.8.14-1 300
300 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

This works

Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

Bug#972293: linux-image-5.8.0-1-amd64: kernel seems to break pulseaudio HDMI sound

[Wesley Schwengle]

Package: src:linux
Version: 5.8.7-1
Severity: important

Dear Maintainer,

When booting with the linux-image-5.8.0-2-amd64 kernel I don't have
sound on my HDMI output. The pulseaudio config hasn't changed yet it
suddenly stopped working after a reboot.

When booting linux-image-5.8.0-1-amd64, the whole setup works again
without fail.

linux-image-5.8.0-1-amd64:
  Installed: 5.8.7-1
  Candidate: 5.8.7-1
  Version table:
 *** 5.8.7-1 100
100 /var/lib/dpkg/status

linux-image-5.8.0-2-amd64:
  Installed: 5.8.10-1
  Candidate: 5.8.10-1
  Version table:
 *** 5.8.10-1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status


-- Package-specific info:
** Version:
Linux version 5.8.0-1-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 
10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 
(2020-09-05)

** Command line:
BOOT_IMAGE=/vmlinuz-5.8.0-1-amd64 root=/dev/mapper/neptune--vg-root ro quiet

** Not tainted

** Kernel log:
[   22.358969] iwlwifi :01:00.0: loaded firmware version 36.79ff3ccf.0 
8265-36.ucode op_mode iwlmvm
[   22.358983] iwlwifi :01:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[   22.439723] audit: type=1400 audit(1602802327.623:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/haveged" pid=597 
comm="apparmor_parser"
[   22.439725] audit: type=1400 audit(1602802327.623:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=595 comm="apparmor_parser"
[   22.439727] audit: type=1400 audit(1602802327.623:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=598 
comm="apparmor_parser"
[   22.439729] audit: type=1400 audit(1602802327.623:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=598 comm="apparmor_parser"
[   22.439795] audit: type=1400 audit(1602802327.623:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libvirtd" pid=593 
comm="apparmor_parser"
[   22.439797] audit: type=1400 audit(1602802327.623:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="libvirtd//qemu_bridge_helper" pid=593 comm="apparmor_parser"
[   22.439816] audit: type=1400 audit(1602802327.623:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=599 
comm="apparmor_parser"
[   22.440324] audit: type=1400 audit(1602802327.623:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="postgresql_akonadi" pid=601 
comm="apparmor_parser"
[   22.442026] audit: type=1400 audit(1602802327.627:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="mariadbd_akonadi" pid=600 
comm="apparmor_parser"
[   22.442752] audit: type=1400 audit(1602802327.627:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=594 
comm="apparmor_parser"
[   22.454588] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
[   22.460583] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   22.479816] iwlwifi :01:00.0: Detected Intel(R) Dual Band Wireless AC 
8265, REV=0x230
[   22.485123] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD (0c45:6717)
[   22.488069] iwlwifi :01:00.0: Applying debug destination EXTERNAL_DRAM
[   22.488351] iwlwifi :01:00.0: Allocated 0x0040 bytes for firmware 
monitor.
[   22.493796] uvcvideo 1-11:1.0: Entity type for entity Extension 4 was not 
initialized!
[   22.493798] uvcvideo 1-11:1.0: Entity type for entity Extension 3 was not 
initialized!
[   22.493799] uvcvideo 1-11:1.0: Entity type for entity Processing 2 was not 
initialized!
[   22.493800] uvcvideo 1-11:1.0: Entity type for entity Camera 1 was not 
initialized!
[   22.493852] input: Integrated_Webcam_HD: Integrate as 
/devices/pci:00/:00:14.0/usb1/1-11/1-11:1.0/input/input30
[   22.493907] usbcore: registered new interface driver uvcvideo
[   22.493907] USB Video Class driver (1.1.1)
[   22.536119] Bluetooth: Core ver 2.22
[   22.536128] NET: Registered protocol family 31
[   22.536129] Bluetooth: HCI device and connection manager initialized
[   22.536132] Bluetooth: HCI socket layer initialized
[   22.536134] Bluetooth: L2CAP socket layer initialized
[   22.536136] Bluetooth: SCO socket layer initialized
[   22.536369] dell_laptop: Using i8042 filter function for receiving events
[   22.536372] intel_rapl_common: Found RAPL domain package
[   22.536374] intel_rapl_common: Found RAPL domain core
[   22.536375] intel_rapl_common: Found RAPL domain uncore
[   22.536375] intel_rapl_common: Found RAPL domain dram
[   22.542568] iwlwifi :01:00.0: base HW address: f8:63:3f:c8:77:15
[   22.610828] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3254: 
line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:line
[   

Bug#972293: linux-image-5.8.0-1-amd64: kernel seems to break pulseaudio HDMI sound

[Wesley Schwengle]

Package: src:linux
Version: 5.8.7-1
Severity: important

Dear Maintainer,

When booting with the linux-image-5.8.0-2-amd64 kernel I don't have
sound on my HDMI output. The pulseaudio config hasn't changed yet it
suddenly stopped working after a reboot.

When booting linux-image-5.8.0-1-amd64, the whole setup works again
without fail.

linux-image-5.8.0-1-amd64:
  Installed: 5.8.7-1
  Candidate: 5.8.7-1
  Version table:
 *** 5.8.7-1 100
100 /var/lib/dpkg/status

linux-image-5.8.0-2-amd64:
  Installed: 5.8.10-1
  Candidate: 5.8.10-1
  Version table:
 *** 5.8.10-1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status


-- Package-specific info:
** Version:
Linux version 5.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 
(2020-09-05)

** Command line:
BOOT_IMAGE=/vmlinuz-5.8.0-1-amd64 root=/dev/mapper/neptune--vg-root ro quiet

** Not tainted

** Kernel log:
[   22.358969] iwlwifi :01:00.0: loaded firmware version 36.79ff3ccf.0 
8265-36.ucode op_mode iwlmvm
[   22.358983] iwlwifi :01:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[   22.439723] audit: type=1400 audit(1602802327.623:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/haveged" pid=597 
comm="apparmor_parser"
[   22.439725] audit: type=1400 audit(1602802327.623:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=595 comm="apparmor_parser"
[   22.439727] audit: type=1400 audit(1602802327.623:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=598 
comm="apparmor_parser"
[   22.439729] audit: type=1400 audit(1602802327.623:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=598 comm="apparmor_parser"
[   22.439795] audit: type=1400 audit(1602802327.623:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libvirtd" pid=593 
comm="apparmor_parser"
[   22.439797] audit: type=1400 audit(1602802327.623:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="libvirtd//qemu_bridge_helper" pid=593 comm="apparmor_parser"
[   22.439816] audit: type=1400 audit(1602802327.623:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=599 
comm="apparmor_parser"
[   22.440324] audit: type=1400 audit(1602802327.623:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="postgresql_akonadi" pid=601 
comm="apparmor_parser"
[   22.442026] audit: type=1400 audit(1602802327.627:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="mariadbd_akonadi" pid=600 
comm="apparmor_parser"
[   22.442752] audit: type=1400 audit(1602802327.627:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=594 
comm="apparmor_parser"
[   22.454588] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
[   22.460583] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   22.479816] iwlwifi :01:00.0: Detected Intel(R) Dual Band Wireless AC 
8265, REV=0x230
[   22.485123] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD (0c45:6717)
[   22.488069] iwlwifi :01:00.0: Applying debug destination EXTERNAL_DRAM
[   22.488351] iwlwifi :01:00.0: Allocated 0x0040 bytes for firmware 
monitor.
[   22.493796] uvcvideo 1-11:1.0: Entity type for entity Extension 4 was not 
initialized!
[   22.493798] uvcvideo 1-11:1.0: Entity type for entity Extension 3 was not 
initialized!
[   22.493799] uvcvideo 1-11:1.0: Entity type for entity Processing 2 was not 
initialized!
[   22.493800] uvcvideo 1-11:1.0: Entity type for entity Camera 1 was not 
initialized!
[   22.493852] input: Integrated_Webcam_HD: Integrate as 
/devices/pci:00/:00:14.0/usb1/1-11/1-11:1.0/input/input30
[   22.493907] usbcore: registered new interface driver uvcvideo
[   22.493907] USB Video Class driver (1.1.1)
[   22.536119] Bluetooth: Core ver 2.22
[   22.536128] NET: Registered protocol family 31
[   22.536129] Bluetooth: HCI device and connection manager initialized
[   22.536132] Bluetooth: HCI socket layer initialized
[   22.536134] Bluetooth: L2CAP socket layer initialized
[   22.536136] Bluetooth: SCO socket layer initialized
[   22.536369] dell_laptop: Using i8042 filter function for receiving events
[   22.536372] intel_rapl_common: Found RAPL domain package
[   22.536374] intel_rapl_common: Found RAPL domain core
[   22.536375] intel_rapl_common: Found RAPL domain uncore
[   22.536375] intel_rapl_common: Found RAPL domain dram
[   22.542568] iwlwifi :01:00.0: base HW address: f8:63:3f:c8:77:15
[   22.610828] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3254: 
line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:line
[   

RE: Heath check responds up even when server is down

[Wesley Lukehart]

Correct - nothing in the logs that show L7TOUT/L7RSP.
I actually change the check interval to 2s when testing so I don't have to wait 
as long when testing.



-Original Message-
From: Christopher Faulet  
Sent: Thursday, October 15, 2020 09:02
To: Wesley Lukehart ; haproxy@formilux.org
Subject: Re: Heath check responds up even when server is down

Le 15/10/2020 à 03:27, Wesley Lukehart a écrit :
> Hello fine people. Short time lurker, first time poster.
> 
> Was on version 2.0.5 with CentOS 7.6 and everything was working fine 
> with Exchange 2019.
> 
> Upgraded to 2.2.3 and now when we put Exchange into maintenance mode 
> HAProxy does not change status - it reports that all services are still up 
> (L7OK/200).
> 
> Example backend:
> 
> backend be_ex2019_oab
> 
>    mode http
> 
>    balance roundrobin
> 
>    option httpchk GET /oab/healthcheck.htm
> 
>    option log-health-checks
> 
>    http-check expect status 200
> 
>    server  :443 check ssl inter 15s verify 
> required ca-file 
> 
>    server  :443 check ssl inter 15s verify 
> required ca-file 
> 
> If I stop the app pool for a service in IIS, or stop all of IIS, 
> HAProxy will properly show the service/services as down - as it gets a 
> non 200 response (503 or 404).
> 
> When putting the Exchange server into maintenance mode, there is no http 
> response.
> 
> When I check with a browser I get "ERR_HTTP2_PROTOCOL_ERROR" or 
> "Secure Connection Failed". Basically no response.
> 
> When I check with wget from the haproxy server I get "HTTP request 
> sent, awaiting response... Read error (Connection reset by peer) in headers."
> 
> Yet HAProxy is happy and continues to try to send mail to the down 
> server - not good.
> 
> Any Ideas?
> 
> I just tried 2.2.4 and no joy.
> 

Hi,

Just to be sure, when you says HAProxy still see the server up, there is no 
Health check errors in your logs ? No  L7TOUT/L7RSP ? Because with your 
configuration and a default "fall" server parameter (3), you should wait at 
least 45s (3 x 15s) to see the server down.

--
Christopher Faulet

RE: Heath check responds up even when server is down

[Wesley Lukehart]

Thanks for the suggestion.
I tried this and there was no change in behavior.



-Original Message-
From: Jarno Huuskonen  
Sent: Thursday, October 15, 2020 00:25
To: Wesley Lukehart ; haproxy@formilux.org
Subject: Re: Heath check responds up even when server is down

Hi,

On Thu, 2020-10-15 at 01:27 +, Wesley Lukehart wrote:
> Hello fine people. Short time lurker, first time poster.
>  
> Was on version 2.0.5 with CentOS 7.6 and everything was working fine 
> with Exchange 2019.
> Upgraded to 2.2.3 and now when we put Exchange into maintenance mode 
> HAProxy does not change status – it reports that all services are 
> still up (L7OK/200).
>  
> Example backend:
> backend be_ex2019_oab
>   mode http
>   balance roundrobin
>   option httpchk GET /oab/healthcheck.htm
>   option log-health-checks
>   http-check expect status 200
>   server  :443 check ssl inter 15s verify 
> required ca-file 
>   server  :443 check ssl inter 15s verify 
> required ca-file 
>  
> If I stop the app pool for a service in IIS, or stop all of IIS, 
> HAProxy will properly show the service/services as down – as it gets a 
> non 200 response (503 or 404).
>  
> When putting the Exchange server into maintenance mode, there is no 
> http response.
> When I check with a browser I get “ERR_HTTP2_PROTOCOL_ERROR” or 
> “Secure Connection Failed”. Basically no response.
> When I check with wget from the haproxy server I get “HTTP request 
> sent, awaiting response... Read error (Connection reset by peer) in headers.”
> Yet HAProxy is happy and continues to try to send mail to the down 
> server – not good.
>  
> Any Ideas?

Does the health check work if you try with something like this:
option httpchk
http-check connect ssl
http-check send meth GET uri /oab/healthcheck.htm ver HTTP/1.1 hdr Host 
somehost.example.org http-check expect status 200 ( 
https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4.2-http-check%20connect
)

-Jarno

--
Jarno Huuskonen

Heath check responds up even when server is down

[Wesley Lukehart]

Hello fine people. Short time lurker, first time poster.

Was on version 2.0.5 with CentOS 7.6 and everything was working fine with 
Exchange 2019.
Upgraded to 2.2.3 and now when we put Exchange into maintenance mode HAProxy 
does not change status - it reports that all services are still up (L7OK/200).

Example backend:
backend be_ex2019_oab
  mode http
  balance roundrobin
  option httpchk GET /oab/healthcheck.htm
  option log-health-checks
  http-check expect status 200
  server  :443 check ssl inter 15s verify required 
ca-file 
  server  :443 check ssl inter 15s verify required 
ca-file 

If I stop the app pool for a service in IIS, or stop all of IIS, HAProxy will 
properly show the service/services as down - as it gets a non 200 response (503 
or 404).

When putting the Exchange server into maintenance mode, there is no http 
response.
When I check with a browser I get "ERR_HTTP2_PROTOCOL_ERROR" or "Secure 
Connection Failed". Basically no response.
When I check with wget from the haproxy server I get "HTTP request sent, 
awaiting response... Read error (Connection reset by peer) in headers."
Yet HAProxy is happy and continues to try to send mail to the down server - not 
good.

Any Ideas?

I just tried 2.2.4 and no joy.

Thanks,

-Luke

Re: [PATCH v10 4/4] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

[Wesley Cheng]

On 10/13/2020 8:03 AM, Rob Herring wrote:
> On Thu, Oct 08, 2020 at 04:59:34PM -0700, Wesley Cheng wrote:
>> Add the required DTS node for the USB VBUS output regulator, which is
>> available on PM8150B.  This will provide the VBUS source to connected
>> peripherals.
>>
>> Signed-off-by: Wesley Cheng 
>> ---
>>  arch/arm64/boot/dts/qcom/pm8150b.dtsi   | 6 ++
>>  arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 4 
>>  2 files changed, 10 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
>> b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
>> index 2bf385f5a55a..49ea597cc0c5 100644
>> --- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
>> @@ -53,6 +53,12 @@ power-on@800 {
>>  status = "disabled";
>>  };
>>  
>> +pm8150b_vbus: regulator@1100 {
>> +compatible = "qcom,pm8150b-vbus-reg";
>> +status = "disabled";
>> +reg = <0x1100>;
>> +};
>> +
>>  pm8150b_typec: usb-typec@1500 {
>>  compatible = "qcom,pm8150b-usb-typec";
>>  status = "disabled";
>> diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts 
>> b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
>> index 6c6325c3af59..ba3b5b802954 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
>> +++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
>> @@ -409,6 +409,10 @@ _mem_phy {
>>  vdda-pll-max-microamp = <19000>;
>>  };
>>  
>> +_vbus {
>> +status = "okay";
>> +};
> 
> Why aren't you enabling the TypeC node and providing a complete example?
> 

Hi Rob,

I have another patch series which enables the type C node and adds QMP
PHY driver changes for setting the SS lane select MUX.

https://patchwork.kernel.org/project/linux-arm-msm/list/?series=361971

Just wanted to work on getting a PMIC based type C driver out there,
which can be utilized in designs where the QMP PHY lane select mux is
not going to be used. (ie using a FUSB340 as a lane select mux instead
of the QMP PHY mux)

Thanks

Regards,
Wesley Cheng

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v10 2/4] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

[Wesley Cheng]

On 10/13/2020 8:00 AM, Rob Herring wrote:
> On Thu, Oct 08, 2020 at 04:59:32PM -0700, Wesley Cheng wrote:
>> Introduce the dt-binding for enabling USB type C orientation and role
>> detection using the PM8150B.  The driver will be responsible for receiving
>> the interrupt at a state change on the CC lines, reading the
>> orientation/role, and communicating this information to the remote
>> clients, which can include a role switch node and a type C switch.
>>
>> Signed-off-by: Wesley Cheng 
>> ---
>>  .../bindings/usb/qcom,pmic-typec.yaml | 115 ++
>>  1 file changed, 115 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml 
>> b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
>> new file mode 100644
>> index ..40e0a296f922
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
>> @@ -0,0 +1,115 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#;
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
>> +
>> +title: Qualcomm PMIC based USB type C Detection Driver
>> +
>> +maintainers:
>> +  - Wesley Cheng 
>> +
>> +description: |
>> +  Qualcomm PMIC Type C Detect
>> +
>> +properties:
>> +  compatible:
>> +enum:
>> +  - qcom,pm8150b-usb-typec
>> +
>> +  reg:
>> +maxItems: 1
>> +description: Type C base address
>> +
>> +  interrupts:
>> +maxItems: 1
>> +description: CC change interrupt from PMIC
>> +
>> +  port:
>> +description: Remote endpoint connection to the DRD switch
>> +type: object
> 
> I don't understand what this is supposed to be. You'll have to expand 
> the example or provide a block diagram of what the connections/routing 
> looks like.
> 

Hi Rob,

The "port" node is going to be the connection to the usb role switch
device, which will be listening for the USB type C port change events.
(i.e handling USB role events, etc...)  In previous patches, this was
part of the connector node, which may not have made much sense, as the
connector model is used to describe the HW connections within a design.
 The role switch endpoint is more of a SW interaction between drivers,
thus the motivation to remove it from the connector node.

I think the current usb-connector design is OK as it is, since the only
component essentially involved in the SS path is the SS MUX that we've
been discussing, and this is true among designs that are supporting SSUSB.


Thanks

Regards,
Wesley Cheng

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Mpi-forum] Virtual Meeting Tomorrow - 2020-10-14

[Wesley Bland via mpi-forum]

Hi all,

We have a virtual meeting scheduled for tomorrow. Here’s the agenda:

* Update on the chapter committee workflow for MPI 4.0 - 
https://github.com/mpi-forum/mpi-issues/wiki#mpi-40-ratification-procedure 
 
* Updates on any in-progress items for MPI 4.0 - 
https://github.com/mpi-forum/mpi-issues/projects/2 
 

If you have any other specific items you’d like to discuss, please send them 
back to the list. Connection information can be found in the usual place:

https://github.com/mpi-forum/mpi-standard/wiki/virtual-forum-meeting-information
 


If you see a 404 error, you’re either not logged into GitHub or you’re not a 
member of the MPI Forum repository. You can probably resolve the first issue 
yourself, and I can help with the second issue if you email me off-list.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [rdo-dev] [rdo-users] [RDO] Weekly Status for 2020-10-09

[Wesley Hayutin]

On Mon, Oct 12, 2020 at 4:59 AM YATIN KAREL  wrote:

> Promotions:-
>   * Latest promotions (TripleO CI):
> * Master: 06th Oct
> * Ussuri: 09th Oct
> * Train(C8): 08th Oct
> * Train(C7): 17th Sept
> * Stein: 08th Oct
>   * Know blocker master
> * https://bugs.launchpad.net/tripleo/+bug/1897947 (octavia component)
> * https://bugs.launchpad.net/tripleo/+bug/1898931 (integration)
>   * Known blocker train(C7)
> * https://review.rdoproject.org/r/#/c/29397/
>
> Packages
>   * Tempest is bumped to 25.0.0 in Ussuri and Train
>   * Octavia-tempest-plugin is pinned in victoria+ due to missing
> deps(httpx)
> * https://review.rdoproject.org/etherpad/p/httpx-centos8-octavia
>
> Victoria Release Preparation
>   * https://review.rdoproject.org/etherpad/p/victoria-release-preparation
>   * Most of the upstream projects have released RC2 bits, all of these
> projects are tagged for release and available in CentOS Mirrors
> * http://mirror.centos.org/centos/8/cloud/x86_64/openstack-victoria/
>   * https://review.rdoproject.org/r/#/q/topic:victoria-branching
>   * openstack/requirements has cut stable/victoria, and now master is
> switched to wallaby tags in rdoinfo
> * https://review.rdoproject.org/r/29934
>   * Victoria jobs are being added by TripleO CI Team
> * https://hackmd.io/sasvoKjTSkabGlFOTkK_kw#bugs-and-reviews
>

Just a quick update here... still a WIP, do not use Victoria for tripleo
deployments.

We did have our first promotion today, /me notes this is NOT with full
coverage yet.
https://trunk.rdoproject.org/api-centos8-victoria/api/civotes_agg_detail.html?ref_hash=13431bf4c5a8ee8c0231f11d43050939
https://trunk.rdoproject.org/centos8-victoria/current-tripleo/
http://images.rdoproject.org/centos8/victoria/rdo_trunk/
https://hub.docker.com/u/tripleovictoria

Nice progress though :)





>
> Other
>   * Implementation of sources verification with GPG signature is on
> progress:
> *
> https://review.rdoproject.org/r/#/q/topic:gpg-verification+(status:open+OR+status:merged)
>
>
> On behalf of RDO
> ___
> users mailing list
> us...@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/users
>
> To unsubscribe: users-unsubscr...@lists.rdoproject.org
>
>
>
>
>
>
> ___
> dev mailing list
> dev@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
>
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-users] [rdo-dev] [RDO] Weekly Status for 2020-10-09

[Wesley Hayutin]

On Mon, Oct 12, 2020 at 4:59 AM YATIN KAREL  wrote:

> Promotions:-
>   * Latest promotions (TripleO CI):
> * Master: 06th Oct
> * Ussuri: 09th Oct
> * Train(C8): 08th Oct
> * Train(C7): 17th Sept
> * Stein: 08th Oct
>   * Know blocker master
> * https://bugs.launchpad.net/tripleo/+bug/1897947 (octavia component)
> * https://bugs.launchpad.net/tripleo/+bug/1898931 (integration)
>   * Known blocker train(C7)
> * https://review.rdoproject.org/r/#/c/29397/
>
> Packages
>   * Tempest is bumped to 25.0.0 in Ussuri and Train
>   * Octavia-tempest-plugin is pinned in victoria+ due to missing
> deps(httpx)
> * https://review.rdoproject.org/etherpad/p/httpx-centos8-octavia
>
> Victoria Release Preparation
>   * https://review.rdoproject.org/etherpad/p/victoria-release-preparation
>   * Most of the upstream projects have released RC2 bits, all of these
> projects are tagged for release and available in CentOS Mirrors
> * http://mirror.centos.org/centos/8/cloud/x86_64/openstack-victoria/
>   * https://review.rdoproject.org/r/#/q/topic:victoria-branching
>   * openstack/requirements has cut stable/victoria, and now master is
> switched to wallaby tags in rdoinfo
> * https://review.rdoproject.org/r/29934
>   * Victoria jobs are being added by TripleO CI Team
> * https://hackmd.io/sasvoKjTSkabGlFOTkK_kw#bugs-and-reviews
>

Just a quick update here... still a WIP, do not use Victoria for tripleo
deployments.

We did have our first promotion today, /me notes this is NOT with full
coverage yet.
https://trunk.rdoproject.org/api-centos8-victoria/api/civotes_agg_detail.html?ref_hash=13431bf4c5a8ee8c0231f11d43050939
https://trunk.rdoproject.org/centos8-victoria/current-tripleo/
http://images.rdoproject.org/centos8/victoria/rdo_trunk/
https://hub.docker.com/u/tripleovictoria

Nice progress though :)





>
> Other
>   * Implementation of sources verification with GPG signature is on
> progress:
> *
> https://review.rdoproject.org/r/#/q/topic:gpg-verification+(status:open+OR+status:merged)
>
>
> On behalf of RDO
> ___
> users mailing list
> users@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/users
>
> To unsubscribe: users-unsubscr...@lists.rdoproject.org
>
>
>
>
>
>
> ___
> dev mailing list
> d...@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
>
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

[cobirds] Townsend's warbler

[Jace Wesley Brasher]

Hello, the Townsend's warbler is one of my favorite birds and I have heard
that it is a bumper year for them. Does anyone have any recommendations on
where I should go to see them and to get decent photography opportunities
with them in Larimer county?
Thanks!

Jace Brasher
Loveland
Larimer county

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyjxRh%3DbSATP-CXhrg-5pW6YOUc%2BogRCpmGUgBfqf7UA0Q%40mail.gmail.com.

[PATCH v2 0/4] Enable USB type C support on SM8150

[Wesley Cheng]

Changes in v2:
 - Added patch to fix a typo in dwc3_qcom_vbus_override_enable()
 - Modified dwc3_qcom_find_usb_connector_match() to search the child nodes for
   the connector device as well
 - Moved out the DRD switch remote endpoint from the connector node in the
   pm8150b_typec device

This series adds support for setting of the orientation multiplexor within the
QMP PHY based on the detection output from the PM8150B.  It will also introduce
a role switch in DWC3 QCOM, which is used so that the DWC3 QCOM glue can receive
role switch change events, and set the vbus override accordingly.  This event
will then be propagated down to the DWC3 core driver, by the DWC3 QCOM getting a
handle to the DWC3 core's role switch.

Wesley Cheng (4):
  arm64: boot: dts: qcom: sm8150: Add nodes for PMIC based typec
detection
  phy: qcom-qmp: Register as a typec switch for orientation detection
  usb: dwc3: dwc3-qcom: Find USB connector and register role switch
  usb: dwc3: dwc3-qcom: Fix typo in the dwc3 vbus override API

 arch/arm64/boot/dts/qcom/sm8150-mtp.dts |  40 +++-
 drivers/phy/qualcomm/Kconfig|  11 ++
 drivers/phy/qualcomm/phy-qcom-qmp.c |  70 -
 drivers/usb/dwc3/dwc3-qcom.c| 128 ++--
 4 files changed, 239 insertions(+), 10 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 4/4] usb: dwc3: dwc3-qcom: Fix typo in the dwc3 vbus override API

[Wesley Cheng]

There was an extra character in the dwc3_qcom_vbus_override_enable()
function.  Removed the extra character.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/dwc3-qcom.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 340760ef0e01..236afbfe01d9 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -107,7 +107,7 @@ static inline void dwc3_qcom_clrbits(void __iomem *base, 
u32 offset, u32 val)
readl(base + offset);
 }
 
-static void dwc3_qcom_vbus_overrride_enable(struct dwc3_qcom *qcom, bool 
enable)
+static void dwc3_qcom_vbus_override_enable(struct dwc3_qcom *qcom, bool enable)
 {
if (enable) {
dwc3_qcom_setbits(qcom->qscratch_base, QSCRATCH_SS_PHY_CTRL,
@@ -128,7 +128,7 @@ static int dwc3_qcom_vbus_notifier(struct notifier_block 
*nb,
struct dwc3_qcom *qcom = container_of(nb, struct dwc3_qcom, vbus_nb);
 
/* enable vbus override for device mode */
-   dwc3_qcom_vbus_overrride_enable(qcom, event);
+   dwc3_qcom_vbus_override_enable(qcom, event);
qcom->mode = event ? USB_DR_MODE_PERIPHERAL : USB_DR_MODE_HOST;
 
return NOTIFY_DONE;
@@ -140,7 +140,7 @@ static int dwc3_qcom_host_notifier(struct notifier_block 
*nb,
struct dwc3_qcom *qcom = container_of(nb, struct dwc3_qcom, host_nb);
 
/* disable vbus override in host mode */
-   dwc3_qcom_vbus_overrride_enable(qcom, !event);
+   dwc3_qcom_vbus_override_enable(qcom, !event);
qcom->mode = event ? USB_DR_MODE_HOST : USB_DR_MODE_PERIPHERAL;
 
return NOTIFY_DONE;
@@ -223,7 +223,7 @@ static int dwc3_qcom_usb_role_switch_set(struct 
usb_role_switch *sw,
 
qcom->mode = (role == USB_ROLE_HOST) ? USB_DR_MODE_HOST :
   USB_DR_MODE_PERIPHERAL;
-   dwc3_qcom_vbus_overrride_enable(qcom, enable);
+   dwc3_qcom_vbus_override_enable(qcom, enable);
return 0;
 }
 
@@ -750,7 +750,7 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
 
/* enable vbus override for device mode */
if (qcom->mode == USB_DR_MODE_PERIPHERAL)
-   dwc3_qcom_vbus_overrride_enable(qcom, true);
+   dwc3_qcom_vbus_override_enable(qcom, true);
 
if (dwc3_qcom_find_usb_connector(pdev)) {
ret = dwc3_qcom_setup_role_switch(qcom);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/4] phy: qcom-qmp: Register as a typec switch for orientation detection

[Wesley Cheng]

The lane select switch for USB typec orientation is within the USB QMP PHY.
the current device.  It could be connected through an endpoint, to an
independent device handling the typec detection, ie the QCOM SPMI typec
driver.

Signed-off-by: Wesley Cheng 
---
 drivers/phy/qualcomm/Kconfig| 11 +
 drivers/phy/qualcomm/phy-qcom-qmp.c | 70 +++--
 2 files changed, 78 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 928db510b86c..43f46a1b3db1 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -48,6 +48,17 @@ config PHY_QCOM_QMP
  Enable this to support the QMP PHY transceiver that is used
  with controllers such as PCIe, UFS, and USB on Qualcomm chips.
 
+if PHY_QCOM_QMP
+config PHY_QCOM_QMP_TYPEC
+   bool "Enable QCOM QMP PHY Type C Switch Support"
+   depends on PHY_QCOM_QMP=y && TYPEC=y || PHY_QCOM_QMP=m && TYPEC
+   help
+ Register a type C switch from the QMP PHY driver for type C
+ orientation support.  This has dependencies with if the type C kernel
+ configuration is enabled or not.  This support will not be present if
+ USB type C is disabled.
+endif
+
 config PHY_QCOM_QUSB2
tristate "Qualcomm QUSB2 PHY Driver"
depends on OF && (ARCH_QCOM || COMPILE_TEST)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 562053ce9455..29d8a3570328 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -66,6 +67,9 @@
 /* QPHY_V3_PCS_MISC_CLAMP_ENABLE register bits */
 #define CLAMP_EN   BIT(0) /* enables i/o clamp_n */
 
+#define SW_PORTSELECT_VAL  BIT(0)
+#define SW_PORTSELECT_MUX  BIT(1)
+
 #define PHY_INIT_COMPLETE_TIMEOUT  1
 #define POWER_DOWN_DELAY_US_MIN10
 #define POWER_DOWN_DELAY_US_MAX11
@@ -1845,6 +1849,8 @@ struct qmp_phy {
  * @phy_initialized: indicate if PHY has been initialized
  * @mode: current PHY mode
  * @ufs_reset: optional UFS PHY reset handle
+ * @sw: typec switch for receiving orientation changes
+ * @orientation: carries current CC orientation
  */
 struct qcom_qmp {
struct device *dev;
@@ -1864,6 +1870,8 @@ struct qcom_qmp {
enum phy_mode mode;
 
struct reset_control *ufs_reset;
+   struct typec_switch *sw;
+   enum typec_orientation orientation;
 };
 
 static inline void qphy_setbits(void __iomem *base, u32 offset, u32 val)
@@ -2485,6 +2493,7 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
void __iomem *pcs = qphy->pcs;
void __iomem *dp_com = qmp->dp_com;
int ret, i;
+   unsigned int val;
 
mutex_lock(>phy_mutex);
if (qmp->init_count++) {
@@ -2534,6 +2543,13 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
qphy_setbits(dp_com, QPHY_V3_DP_COM_PHY_MODE_CTRL,
 USB3_MODE | DP_MODE);
 
+   if (cfg->is_dual_lane_phy) {
+   val = SW_PORTSELECT_MUX;
+   if (qmp->orientation == TYPEC_ORIENTATION_REVERSE)
+   val |= SW_PORTSELECT_VAL;
+   qphy_setbits(dp_com, QPHY_V3_DP_COM_TYPEC_CTRL, val);
+   }
+
/* bring both QMP USB and QMP DP PHYs PCS block out of reset */
qphy_clrbits(dp_com, QPHY_V3_DP_COM_RESET_OVRD_CTRL,
 SW_DPPHY_RESET_MUX | SW_DPPHY_RESET |
@@ -2559,7 +2575,7 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
 
if (cfg->has_phy_com_ctrl) {
void __iomem *status;
-   unsigned int mask, val;
+   unsigned int mask;
 
qphy_clrbits(serdes, cfg->regs[QPHY_COM_SW_RESET], SW_RESET);
qphy_setbits(serdes, cfg->regs[QPHY_COM_START_CONTROL],
@@ -3242,6 +3258,47 @@ static const struct dev_pm_ops qcom_qmp_phy_pm_ops = {
   qcom_qmp_phy_runtime_resume, NULL)
 };
 
+#if IS_ENABLED(CONFIG_PHY_QCOM_QMP_TYPEC)
+static int qcom_qmp_phy_typec_switch_set(struct typec_switch *sw,
+enum typec_orientation orientation)
+{
+   struct qcom_qmp *qmp = typec_switch_get_drvdata(sw);
+   struct qmp_phy *qphy = qmp->phys[0];
+
+   qmp->orientation = orientation;
+   if (qmp->phy_initialized) {
+   qcom_qmp_phy_disable(qphy->phy);
+   qcom_qmp_phy_enable(qphy->phy);
+   }
+
+   return 0;
+}
+
+static int qcom_qmp_phy_typec_switch_register(struct qcom_qmp *qmp)
+{
+   struct typec_switch_desc sw_desc;
+   struct device *dev = qmp-&

[PATCH v2 1/4] arm64: boot: dts: qcom: sm8150: Add nodes for PMIC based typec detection

[Wesley Cheng]

Introduce required child nodes to enable the PMIC based USB type C driver.
This consits of connector and endpoint nodes to drivers, which manage the
type C mux and the USB role switch.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 40 -
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts 
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index ba3b5b802954..06ad01dde080 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -413,6 +413,31 @@ _vbus {
status = "okay";
 };
 
+_typec {
+   status = "okay";
+   connector {
+   compatible = "usb-c-connector";
+   power-role = "dual";
+   data-role = "dual";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@1 {
+   reg = <1>;
+   usb3_data_ss: endpoint@0 {
+   remote-endpoint = <_ss_mux>;
+   };
+   };
+   };
+   };
+
+   port {
+   usb3_role: endpoint {
+   remote-endpoint = <_drd_switch>;
+   };
+   };
+};
+
 _1_hsphy {
status = "okay";
vdda-pll-supply = <_usb_hs_core>;
@@ -424,12 +449,25 @@ _1_qmpphy {
status = "okay";
vdda-phy-supply = <_l3c_1p2>;
vdda-pll-supply = <_usb_ss_dp_core_1>;
+   orientation-switch;
+   port {
+   qmp_ss_mux: endpoint@0 {
+   remote-endpoint = <_data_ss>;
+   };
+   };
 };
 
 _1 {
status = "okay";
+   usb-role-switch;
+   port {
+   dwc3_drd_switch: endpoint@0 {
+   remote-endpoint = <_role>;
+   };
+   };
 };
 
 _1_dwc3 {
-   dr_mode = "peripheral";
+   dr_mode = "otg";
+   usb-role-switch;
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 3/4] usb: dwc3: dwc3-qcom: Find USB connector and register role switch

[Wesley Cheng]

If registering a USB typeC connector, the connector node may not be a child
of the DWC3 QCOM device.  Utilize devcon graph search to lookup if any
remote endpoints contain the connector.  If a connector is present, the
DWC3 QCOM will register a USB role switch to receive role change events, as
well as attain a reference to the DWC3 core role switch to pass the event
down.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/dwc3-qcom.c | 120 ++-
 1 file changed, 118 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index e1e78e9824b1..340760ef0e01 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "core.h"
 
@@ -71,6 +73,9 @@ struct dwc3_qcom {
struct notifier_block   vbus_nb;
struct notifier_block   host_nb;
 
+   struct usb_role_switch *role_sw;
+   struct usb_role_switch *dwc3_drd_sw;
+
const struct dwc3_acpi_pdata *acpi_pdata;
 
enum usb_dr_modemode;
@@ -190,6 +195,73 @@ static int dwc3_qcom_register_extcon(struct dwc3_qcom 
*qcom)
return 0;
 }
 
+static int dwc3_qcom_usb_role_switch_set(struct usb_role_switch *sw,
+enum usb_role role)
+{
+   struct dwc3_qcom *qcom = usb_role_switch_get_drvdata(sw);
+   struct fwnode_handle *child;
+   bool enable = false;
+
+   if (!qcom->dwc3_drd_sw) {
+   child = device_get_next_child_node(qcom->dev, NULL);
+   if (child) {
+   qcom->dwc3_drd_sw = 
usb_role_switch_find_by_fwnode(child);
+   fwnode_handle_put(child);
+   if (IS_ERR(qcom->dwc3_drd_sw)) {
+   qcom->dwc3_drd_sw = NULL;
+   return 0;
+   }
+   }
+   }
+
+   usb_role_switch_set_role(qcom->dwc3_drd_sw, role);
+
+   if (role == USB_ROLE_DEVICE)
+   enable = true;
+   else
+   enable = false;
+
+   qcom->mode = (role == USB_ROLE_HOST) ? USB_DR_MODE_HOST :
+  USB_DR_MODE_PERIPHERAL;
+   dwc3_qcom_vbus_overrride_enable(qcom, enable);
+   return 0;
+}
+
+static enum usb_role dwc3_qcom_usb_role_switch_get(struct usb_role_switch *sw)
+{
+   struct dwc3_qcom *qcom = usb_role_switch_get_drvdata(sw);
+   enum usb_role role;
+
+   switch (qcom->mode) {
+   case USB_DR_MODE_HOST:
+   role = USB_ROLE_HOST;
+   break;
+   case USB_DR_MODE_PERIPHERAL:
+   role = USB_ROLE_DEVICE;
+   break;
+   default:
+   role = USB_ROLE_DEVICE;
+   break;
+   }
+
+   return role;
+}
+
+static int dwc3_qcom_setup_role_switch(struct dwc3_qcom *qcom)
+{
+   struct usb_role_switch_desc dwc3_role_switch = {NULL};
+
+   dwc3_role_switch.fwnode = dev_fwnode(qcom->dev);
+   dwc3_role_switch.set = dwc3_qcom_usb_role_switch_set;
+   dwc3_role_switch.get = dwc3_qcom_usb_role_switch_get;
+   dwc3_role_switch.driver_data = qcom;
+   qcom->role_sw = usb_role_switch_register(qcom->dev, _role_switch);
+   if (IS_ERR(qcom->role_sw))
+   return PTR_ERR(qcom->role_sw);
+
+   return 0;
+}
+
 static void dwc3_qcom_disable_interrupts(struct dwc3_qcom *qcom)
 {
if (qcom->hs_phy_irq) {
@@ -540,6 +612,42 @@ static int dwc3_qcom_of_register_core(struct 
platform_device *pdev)
return 0;
 }
 
+static int dwc3_qcom_connector_check(struct fwnode_handle *fwnode)
+{
+   if (fwnode && (!fwnode_property_match_string(fwnode, "compatible",
+"gpio-usb-b-connector") ||
+   !fwnode_property_match_string(fwnode, "compatible",
+ "usb-c-connector")))
+   return 1;
+
+   return 0;
+}
+
+static void *dwc3_qcom_find_usb_connector_match(struct device_connection *con,
+   int ep, void *data)
+{
+   struct fwnode_handle *fwnode;
+
+   /* Check if the "connector" node is the parent of the remote endpoint */
+   if (dwc3_qcom_connector_check(con->fwnode))
+   return fwnode;
+
+   /* else, check if it is a child node */
+   fwnode = fwnode_get_named_child_node(con->fwnode, "connector");
+   if (dwc3_qcom_connector_check(fwnode))
+   return fwnode;
+
+   return 0;
+}
+
+static bool dwc3_qcom_find_usb_connector(struct platform_device *pdev)
+{
+   struct fwnode_handle *fwnode = pdev->dev.fwnode;
+
+   return fwnode_connection_find_match(fwnode, "connector", NULL,
+ 

[PATCH v10 2/4] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

[Wesley Cheng]

Introduce the dt-binding for enabling USB type C orientation and role
detection using the PM8150B.  The driver will be responsible for receiving
the interrupt at a state change on the CC lines, reading the
orientation/role, and communicating this information to the remote
clients, which can include a role switch node and a type C switch.

Signed-off-by: Wesley Cheng 
---
 .../bindings/usb/qcom,pmic-typec.yaml | 115 ++
 1 file changed, 115 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml

diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml 
b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index ..40e0a296f922
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Qualcomm PMIC based USB type C Detection Driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  Qualcomm PMIC Type C Detect
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-usb-typec
+
+  reg:
+maxItems: 1
+description: Type C base address
+
+  interrupts:
+maxItems: 1
+description: CC change interrupt from PMIC
+
+  port:
+description: Remote endpoint connection to the DRD switch
+type: object
+
+properties:
+  endpoint:
+description: Connection to the DRD switch being used
+type: object
+
+  connector:
+$ref: /connector/usb-connector.yaml#
+description: Connector type for remote endpoints
+type: object
+
+properties:
+  compatible:
+enum:
+  - usb-c-connector
+
+  power-role: true
+  data-role: true
+
+  ports:
+description: Remote endpoint connections for type C paths
+type: object
+
+properties:
+  port@1:
+description: Remote endpoints for the Super Speed path
+type: object
+
+properties:
+  endpoint:
+description: Connection to USB type C mux node
+type: object
+
+required:
+  - compatible
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - connector
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+pm8150b_typec: usb-typec@1500 {
+compatible = "qcom,pm8150b-usb-typec";
+reg = <0x1500>;
+interrupts = <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+
+port {
+usb3_role: endpoint {
+remote-endpoint = <_drd_switch>;
+};
+};
+
+connector {
+compatible = "usb-c-connector";
+power-role = "dual";
+data-role = "dual";
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+};
+port@1 {
+reg = <1>;
+#address-cells = <1>;
+#size-cells = <0>;
+usb3_data_ss: endpoint {
+remote-endpoint = <_ss_mux>;
+};
+};
+};
+};
+};
+};
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v10 1/4] usb: typec: Add QCOM PMIC typec detection driver

[Wesley Cheng]

The QCOM SPMI typec driver handles the role and orientation detection, and
notifies client drivers using the USB role switch framework.   It registers
as a typec port, so orientation can be communicated using the typec switch
APIs.  The driver also attains a handle to the VBUS output regulator, so it
can enable/disable the VBUS source when acting as a host/device.

Signed-off-by: Wesley Cheng 
Acked-by: Heikki Krogerus 
Reviewed-by: Stephen Boyd 
---
 drivers/usb/typec/Kconfig   |  12 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/qcom-pmic-typec.c | 262 
 3 files changed, 275 insertions(+)
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 559dd06117e7..63789cf88fce 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -73,6 +73,18 @@ config TYPEC_TPS6598X
  If you choose to build this driver as a dynamically linked module, the
  module will be called tps6598x.ko.
 
+config TYPEC_QCOM_PMIC
+   tristate "Qualcomm PMIC USB Type-C driver"
+   depends on ARCH_QCOM || COMPILE_TEST
+   help
+ Driver for supporting role switch over the Qualcomm PMIC.  This will
+ handle the USB Type-C role and orientation detection reported by the
+ QCOM PMIC if the PMIC has the capability to handle USB Type-C
+ detection.
+
+ It will also enable the VBUS output to connected devices when a
+ DFP connection is made.
+
 source "drivers/usb/typec/mux/Kconfig"
 
 source "drivers/usb/typec/altmodes/Kconfig"
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 7753a5c3cd46..cceffd987643 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_TYPEC_TCPM)+= tcpm/
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
 obj-$(CONFIG_TYPEC_HD3SS3220)  += hd3ss3220.o
 obj-$(CONFIG_TYPEC_TPS6598X)   += tps6598x.o
+obj-$(CONFIG_TYPEC_QCOM_PMIC)  += qcom-pmic-typec.o
 obj-$(CONFIG_TYPEC)+= mux/
diff --git a/drivers/usb/typec/qcom-pmic-typec.c 
b/drivers/usb/typec/qcom-pmic-typec.c
new file mode 100644
index ..a0454a80c4a2
--- /dev/null
+++ b/drivers/usb/typec/qcom-pmic-typec.c
@@ -0,0 +1,262 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TYPEC_MISC_STATUS  0xb
+#define CC_ATTACHEDBIT(0)
+#define CC_ORIENTATION BIT(1)
+#define SNK_SRC_MODE   BIT(6)
+#define TYPEC_MODE_CFG 0x44
+#define TYPEC_DISABLE_CMD  BIT(0)
+#define EN_SNK_ONLYBIT(1)
+#define EN_SRC_ONLYBIT(2)
+#define TYPEC_VCONN_CONTROL0x46
+#define VCONN_EN_SRC   BIT(0)
+#define VCONN_EN_VAL   BIT(1)
+#define TYPEC_EXIT_STATE_CFG   0x50
+#define SEL_SRC_UPPER_REF  BIT(2)
+#define TYPEC_INTR_EN_CFG_10x5e
+#define TYPEC_INTR_EN_CFG_1_MASK   GENMASK(7, 0)
+
+struct qcom_pmic_typec {
+   struct device   *dev;
+   struct regmap   *regmap;
+   u32 base;
+
+   struct typec_port   *port;
+   struct usb_role_switch *role_sw;
+
+   struct regulator*vbus_reg;
+   boolvbus_enabled;
+};
+
+static void qcom_pmic_typec_enable_vbus_regulator(struct qcom_pmic_typec
+   *qcom_usb, bool enable)
+{
+   int ret;
+
+   if (enable == qcom_usb->vbus_enabled)
+   return;
+
+   if (enable) {
+   ret = regulator_enable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   } else {
+   ret = regulator_disable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   }
+   qcom_usb->vbus_enabled = enable;
+}
+
+static void qcom_pmic_typec_check_connection(struct qcom_pmic_typec *qcom_usb)
+{
+   enum typec_orientation orientation;
+   enum usb_role role;
+   unsigned int stat;
+   bool enable_vbus;
+
+   regmap_read(qcom_usb->regmap, qcom_usb->base + TYPEC_MISC_STATUS,
+   );
+
+   if (stat & CC_ATTACHED) {
+   orientation = (stat & CC_ORIENTATION) ?
+   TYPEC_ORIENTATION_REVERSE :
+   TYPEC_ORIENTATION_NORMAL;
+   typec_set_orientation(qcom_usb->port, orientation);
+
+   role = (stat & SNK_SRC_MODE) ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+   if (role == USB_ROLE_HOST)
+   enable_vbus = true;
+   e

[PATCH v10 4/4] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

[Wesley Cheng]

Add the required DTS node for the USB VBUS output regulator, which is
available on PM8150B.  This will provide the VBUS source to connected
peripherals.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi   | 6 ++
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 4 
 2 files changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 2bf385f5a55a..49ea597cc0c5 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -53,6 +53,12 @@ power-on@800 {
status = "disabled";
};
 
+   pm8150b_vbus: regulator@1100 {
+   compatible = "qcom,pm8150b-vbus-reg";
+   status = "disabled";
+   reg = <0x1100>;
+   };
+
pm8150b_typec: usb-typec@1500 {
compatible = "qcom,pm8150b-usb-typec";
status = "disabled";
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts 
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6c6325c3af59..ba3b5b802954 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -409,6 +409,10 @@ _mem_phy {
vdda-pll-max-microamp = <19000>;
 };
 
+_vbus {
+   status = "okay";
+};
+
 _1_hsphy {
status = "okay";
vdda-pll-supply = <_usb_hs_core>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v10 0/4] Introduce PMIC based USB type C detection

[Wesley Cheng]

Changes in v10:
 - Modified the type c dt-binding to remove the DRD switch node outside of the
   connector, as it is more of a SW entity, whereas the USB connector model
   focuses more on how the connector pins are connected in the HW design.  The
   binding now matches what is specified in the usb-connector binding.
 - Change the fwnode to search for the remote endpoint referencing the usb role
   switch device in qcom-pmic-typec
 - Rename typec node from "typec" to "usb-typec"

Changes in v9:
 - Fixed dt-binding to reference usb-connector from the 'connector' node,
   removed properties that didn't have further constraints (than specified in
   usb-connector.yaml), and make 'reg' a required property.
 - Moved vbus_reg get call into probe(), and will fail if the regulator is not
   available.
 - Removed some references from qcom_pmic_typec, as they were not needed after
   probe().
 - Moved interrupt registration until after all used variables were initialized.

Changes in v8:
 - Simplified some property definitions, and corrected the
   connector reference in the dt binding.

Changes in v7:
 - Fixups in qcom-pmic-typec.c to remove uncesscary includes, printk formatting,
   and revising some logic operations. 

Changes in v6:
 - Removed qcom_usb_vbus-regulator.c and qcom,usb-vbus-regulator.yaml from the
   series as they have been merged on regulator.git
 - Added separate references to the usb-connector.yaml in qcom,pmic-typec.yaml
   instead of referencing the entire schema.

Changes in v5:
 - Fix dt_binding_check warning/error in qcom,pmic-typec.yaml

Changes in v4:
 - Modified qcom,pmic-typec binding to include the SS mux and the DRD remote
   endpoint nodes underneath port@1, which is assigned to the SSUSB path
   according to usb-connector
 - Added usb-connector reference to the typec dt-binding
 - Added tags to the usb type c and vbus nodes
 - Removed "qcom" tags from type c and vbus nodes
 - Modified Kconfig module name, and removed module alias from the typec driver
 
Changes in v3:
 - Fix driver reference to match driver name in Kconfig for
   qcom_usb_vbus-regulator.c
 - Utilize regulator bitmap helpers for enable, disable and is enabled calls in
   qcom_usb_vbus-regulator.c
 - Use of_get_regulator_init_data() to initialize regulator init data, and to
   set constraints in qcom_usb_vbus-regulator.c
 - Remove the need for a local device structure in the vbus regulator driver
 
Changes in v2:
 - Use devm_kzalloc() in qcom_pmic_typec_probe()
 - Add checks to make sure return value of typec_find_port_power_role() is
   valid
 - Added a VBUS output regulator driver, which will be used by the PMIC USB
   type c driver to enable/disable the source
 - Added logic to control vbus source from the PMIC type c driver when
   UFP/DFP is detected
 - Added dt-binding for this new regulator driver
 - Fixed Kconfig typec notation to match others
 - Leave type C block disabled until enabled by a platform DTS

Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC.  Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this.  This
series adds the dt-binding, PMIC type C driver, and DTS nodes.

The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications.  It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.

Wesley Cheng (4):
  usb: typec: Add QCOM PMIC typec detection driver
  dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
  arm64: boot: dts: qcom: pm8150b: Add node for USB type C block
  arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

 .../bindings/usb/qcom,pmic-typec.yaml | 115 
 arch/arm64/boot/dts/qcom/pm8150b.dtsi |  13 +
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts   |   4 +
 drivers/usb/typec/Kconfig |  12 +
 drivers/usb/typec/Makefile|   1 +
 drivers/usb/typec/qcom-pmic-typec.c   | 262 ++
 6 files changed, 407 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v10 3/4] arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

[Wesley Cheng]

The PM8150B has a dedicated USB type C block, which can be used for type C
orientation and role detection.  Create the reference node to this type C
block for further use.

Signed-off-by: Wesley Cheng 
Reviewed-by: Bjorn Andersson 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index e112e8876db6..2bf385f5a55a 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -53,6 +53,13 @@ power-on@800 {
status = "disabled";
};
 
+   pm8150b_typec: usb-typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   status = "disabled";
+   reg = <0x1500>;
+   interrupts = <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
pm8150b_temp: temp-alarm@2400 {
compatible = "qcom,spmi-temp-alarm";
reg = <0x2400>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [Mpi-forum] [EXTERNAL] Last Call for MPI 4.0 Issues

[Wesley Bland via mpi-forum]

Yes. Sorry I was unclear on the title there. That’s correct.

> On Oct 7, 2020, at 12:34 PM, Pritchard Jr., Howard  wrote:
> 
> HI Wesley,
>  
> By project do you mean the MPI 4.0 ratification?
>  
> Howard
>  
> From: mpi-forum  <mailto:mpi-forum-boun...@lists.mpi-forum.org>> on behalf of mpi-forum 
> mailto:mpi-forum@lists.mpi-forum.org>>
> Reply-To: mpi-forum  <mailto:mpi-forum@lists.mpi-forum.org>>
> Date: Wednesday, October 7, 2020 at 11:11 AM
> To: mpi-forum  <mailto:mpi-forum@lists.mpi-forum.org>>
> Cc: Wesley Bland mailto:w...@wesbland.com>>
> Subject: [EXTERNAL] [Mpi-forum] Last Call for MPI 4.0 Issues
>  
> Hi all, 
>  
> (Action Item for everyone in bold below)
>  
> For those of you who couldn’t attend the last day of last week’s MPI Forum 
> meeting, I’d highly recommend that you want the presentation I gave about the 
> process we’ll be going through over the next few months to ratify MPI 4.0. 
> The video is available here:
>  
> https://youtu.be/zX1XneiVTUg?t=2249 <https://youtu.be/zX1XneiVTUg?t=2249> 
> (starts at 37:40)
>  
> You can also find the slides here:
>  
> https://github.com/mpi-forum/mpi-forum.github.io/blob/master/slides/2020/09/2020-09-30-rcm-frm-procedures.pptx?raw=true
>  
> <https://github.com/mpi-forum/mpi-forum.github.io/blob/master/slides/2020/09/2020-09-30-rcm-frm-procedures.pptx?raw=true>
>  
>  
> As part of the virtual meeting next week, I plan to hold “office hours” to 
> answer any questions people may have about that. I’ll also be going over the 
> details of exactly how some of these pieces will work where I left some gaps 
> in the original presentation (e.g., What will the Git branches look like? How 
> do we make PRs? Where do the issues go?). Everyone who will be helping review 
> the Standard before December should plan to attend (that’s everyone who’s 
> attended 3 meetings this year), chapter committees in particular.
>  
> In anticipation of that, each person should go through any issues or pull 
> requests that they’ve opened on GitHub and see if there are any last minute 
> items for MPI 4.0. I made a pass through every PR today and cleaned up quite 
> a few, but there may still be some that need to be added to the agenda. To do 
> this, go find all of the issues where you are either an author or an assignee 
> (you can find how to do that in the attached image) and decide whether it 
> should be for MPI 4.0, MPI 4.1, MPI 5.0, or closed. There are labels for the 
> first three and you can just close it for the last one. As usual, if you have 
> questions, just ask me. If you want it to be in MPI 4.0, please also add it 
> to the MPI 4.0 “project” so we’ll be able to track it.
>  
> 
>  
> Please note that anything that is going into MPI 4.0 really needs to be 
> called out in the next few weeks. Bill will be generating the release 
> candidate at the beginning of November and everything needs to be merged 
> before that happens. If something gets missed this month, it will probably 
> have to wait for MPI 4.1.
>  
> Thanks,
> Wes

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] Virtual Meeting Tomorrow

[Wesley Bland via mpi-forum]

I didn’t hear any requests so today’s virtual meeting is cancelled.

Thanks,
Wes

> On Oct 6, 2020, at 6:43 PM, Wesley Bland  wrote:
> 
> Hi all,
> 
> We have a virtual meeting scheduled for tomorrow at the usual time 10am US 
> Central. The agenda is anything from the various chapter committees to start 
> getting ready for MPI 4.0. Are any committees ready to present anything? 
> 
> If I don’t hear anything tonight, I’ll assume that we should start up next 
> week. I ought to have some more detailed guidance about how to do the git 
> reviews then. 
> 
> Thanks,
> Wes

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[Mpi-forum] Virtual Meeting Tomorrow

[Wesley Bland via mpi-forum]

Hi all,

We have a virtual meeting scheduled for tomorrow at the usual time 10am US 
Central. The agenda is anything from the various chapter committees to start 
getting ready for MPI 4.0. Are any committees ready to present anything? 

If I don’t hear anything tonight, I’ll assume that we should start up next 
week. I ought to have some more detailed guidance about how to do the git 
reviews then. 

Thanks,
Wes
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [racket-users] Pattern Matching

[Wesley Bitomski]

Hello Beatriz,

Is this something like contracts with parameters? That sounds neat, 
actually.

Anyway, this seems more like syntax analysis rather than string matching, 
but I'm not entirely certain as to what your approach is. I can't access 
the file you linked.

If this _is_ syntax analysis, then maybe a macro using `syntax-case` or 
`syntax-parse` would serve you better? Again, I'm not exactly sure what 
your approach is, and I'm sorry for that.
On Monday, September 28, 2020 at 3:31:11 PM UTC-4 gneuner2 wrote:

>
> On 9/28/2020 10:50 AM, Beatriz Moreira wrote:
>
> Hello, 
> I would like to know how do I match multiple variables to a regular 
> expression.
> My idea is to match every *f* variables (f...) to an *f* in ((contract C 
> ((T x) ...) ((T f)) ...) ... ).
> I am trying to implement a core language for smart contracts in Racket, 
> but I need to have as pre condition in my reduction rules that the *f* is 
> a function in one of the contracts.
> Thank you! :) 
>
>
> 'regexp-match*' outputs a list of matched strings, and match has an apply 
> clause: '(app *expr* pats ...)' which evaluates *expr* and tries to match 
> the output.  My first thought would be to try something like:
>
>   match ( inp )
> :
> ((app (regexp-match* pattern inp) match1 match2 ... )
>... )
> :
>
> Caveat ... I've never tried to do this.  If match doesn't like this 
> approach (or something close to it), then I would separately perform the 
> regexp-match* and the pattern match on its output list.
>
> Hope this helps,
> George
>
> https://docs.racket-lang.org/reference/regexp.html
> https://docs.racket-lang.org/reference/match.html
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/236fecf4-e123-472e-9c86-dc9c88dc71c5n%40googlegroups.com.

[PATCH v4] usb: dwc3: Stop active transfers before halting the controller

[Wesley Cheng]

In the DWC3 databook, for a device initiated disconnect or bus reset, the
driver is required to send dependxfer commands for any pending transfers.
In addition, before the controller can move to the halted state, the SW
needs to acknowledge any pending events.  If the controller is not halted
properly, there is a chance the controller will continue accessing stale or
freed TRBs and buffers.

Signed-off-by: Wesley Cheng 
Reviewed-by: Thinh Nguyen 

---
Changes in v4:
 - Updated comments to reference DWC3 databook sections and added direct
   quotes.
 - Changed the stop active transfer EP loop to use dwc->num_eps.
 - Moved to using dwc3_gadget_disable_irq/synchronize_irq instead of
   enable_irq/disable_irq for ensuring the interrupt handler is not pending.

Changes in v3:
 - Removed DWC3_EP_ENABLED check from dwc3_gadget_stop_active_transfers()
   as dwc3_stop_active_transfer() has a check already in place.
 - Calling __dwc3_gadget_stop() which ensures that DWC3 interrupt events
   are cleared, and ep0 eps are cleared for the pullup disabled case.  Not
   required to call __dwc3_gadget_start() on pullup enable, as the
   composite driver will execute udc_start() before calling pullup().

Changes in v2:
 - Moved cleanup code to the pullup() API to differentiate between device
   disconnect and hibernation.
 - Added cleanup code to the bus reset case as well.
 - Verified the move to pullup() did not reproduce the problen using the
   same test sequence.

Verified fix by adding a check for ETIMEDOUT during the run stop call.
Shell script writing to the configfs UDC file to trigger disconnect and
connect.  Batch script to have PC execute data transfers over adb (ie adb
push)  After a few iterations, we'd run into a scenario where the
controller wasn't halted.  With the following change, no failed halts after
many iterations.
---
 drivers/usb/dwc3/ep0.c|  2 +-
 drivers/usb/dwc3/gadget.c | 66 ++-
 2 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 59f2e8c31bd1..456aa87e8778 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -197,7 +197,7 @@ int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct 
usb_request *request,
int ret;
 
spin_lock_irqsave(>lock, flags);
-   if (!dep->endpoint.desc) {
+   if (!dep->endpoint.desc || !dwc->pullups_connected) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
dep->name);
ret = -ESHUTDOWN;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 3ab6f118c508..5d879b7606d5 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1516,7 +1516,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
 {
struct dwc3 *dwc = dep->dwc;
 
-   if (!dep->endpoint.desc) {
+   if (!dep->endpoint.desc || !dwc->pullups_connected) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
dep->name);
return -ESHUTDOWN;
@@ -1926,6 +1926,21 @@ static int dwc3_gadget_set_selfpowered(struct usb_gadget 
*g,
return 0;
 }
 
+static void dwc3_stop_active_transfers(struct dwc3 *dwc)
+{
+   u32 epnum;
+
+   for (epnum = 2; epnum < dwc->num_eps; epnum++) {
+   struct dwc3_ep *dep;
+
+   dep = dwc->eps[epnum];
+   if (!dep)
+   continue;
+
+   dwc3_remove_requests(dwc, dep);
+   }
+}
+
 static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
 {
u32 reg;
@@ -1971,6 +1986,9 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int 
is_on, int suspend)
return 0;
 }
 
+static void dwc3_gadget_disable_irq(struct dwc3 *dwc);
+static void __dwc3_gadget_stop(struct dwc3 *dwc);
+
 static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
 {
struct dwc3 *dwc = gadget_to_dwc(g);
@@ -1994,7 +2012,46 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
}
}
 
+   /*
+* Synchronize any pending event handling before executing the 
controller
+* halt routine.
+*/
+   if (!is_on) {
+   dwc3_gadget_disable_irq(dwc);
+   synchronize_irq(dwc->irq_gadget);
+   }
+
spin_lock_irqsave(>lock, flags);
+
+   if (!is_on) {
+   u32 count;
+
+   /*
+* In the Synopsis DesignWare Cores USB3 Databook Rev. 3.30a
+* Section 4.1.8 Table 4-7, it states that for a 
device-initiated
+* disconnect, the SW needs to ensure that it sends "a 
DEPENDXFER
+* comma

[Mpi-forum] MPI Forum Meeting Registration

[Wesley Bland via mpi-forum]

Hi all,

In all the excitement with the EuroMPI Conference last week, I forgot to send 
out a reminder to register for the upcoming MPI Forum meeting. The page has 
been posted for a while, but I don’t think I ever sent out an email.

For everyone who will be attending, please register ASAP. The deadline is 11:30 
AM US Central on Monday as that is the announced time for the first voting 
block.

https://forms.gle/wePXwqJZfuhH7DyX7

The votes are also posted on the agenda page already and I’ll be updating the 
voting page in the next few minutes. There was one vote that was announced but 
missed on the agenda page. As a reminder, there will be a “no-no” vote on #137: 
“The Embiggenment”.

Thanks,
Wes
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum