[PATCH v3] usb: dwc3: gadget: Prevent EP queuing while stopping transfers

[Wesley Cheng]

In the situations where the DWC3 gadget stops active transfers, once
calling the dwc3_gadget_giveback(), there is a chance where a function
driver can queue a new USB request in between the time where the dwc3
lock has been released and re-aquired.  This occurs after we've already
issued an ENDXFER command.  When the stop active transfers continues
to remove USB requests from all dep lists, the newly added request will
also be removed, while controller still has an active TRB for it.
This can lead to the controller accessing an unmapped memory address.

Fix this by ensuring parameters to prevent EP queuing are set before
calling the stop active transfers API.

Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the 
controller")
Signed-off-by: Wesley Cheng 
---
Changes since V2:
 - Removed duplicate dwc->connected = false setting in pullup routine

Changes since V1:
 - Added Fixes tag to point to the commit this is addressing

 drivers/usb/dwc3/gadget.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4780983..2c94cc9 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -783,8 +783,6 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
 
trace_dwc3_gadget_ep_disable(dep);
 
-   dwc3_remove_requests(dwc, dep);
-
/* make sure HW endpoint isn't stalled */
if (dep->flags & DWC3_EP_STALL)
__dwc3_gadget_ep_set_halt(dep, 0, false);
@@ -803,6 +801,8 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
dep->endpoint.desc = NULL;
}
 
+   dwc3_remove_requests(dwc, dep);
+
return 0;
 }
 
@@ -1617,7 +1617,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
 {
struct dwc3 *dwc = dep->dwc;
 
-   if (!dep->endpoint.desc || !dwc->pullups_connected) {
+   if (!dep->endpoint.desc || !dwc->pullups_connected || !dwc->connected) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
dep->name);
return -ESHUTDOWN;
@@ -2247,6 +2247,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
if (!is_on) {
u32 count;
 
+   dwc->connected = false;
/*
 * In the Synopsis DesignWare Cores USB3 Databook Rev. 3.30a
 * Section 4.1.8 Table 4-7, it states that for a 
device-initiated
@@ -2271,7 +2272,6 @@ 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;
} else {
__dwc3_gadget_start(dwc);
}
@@ -3329,8 +3329,6 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
 {
u32 reg;
 
-   dwc->connected = true;
-
/*
 * WORKAROUND: DWC3 revisions <1.88a have an issue which
 * would cause a missing Disconnect Event if there's a
@@ -3370,6 +3368,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
 * transfers."
 */
dwc3_stop_active_transfers(dwc);
+   dwc->connected = true;
 
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_TSTCTRL_MASK;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] usb: dwc3: gadget: Prevent EP queuing while stopping transfers

[Wesley Cheng]

On 3/11/2021 3:18 PM, Thinh Nguyen wrote:
> Wesley Cheng wrote:
>> In the situations where the DWC3 gadget stops active transfers, once
>> calling the dwc3_gadget_giveback(), there is a chance where a function
>> driver can queue a new USB request in between the time where the dwc3
>> lock has been released and re-aquired.  This occurs after we've already
>> issued an ENDXFER command.  When the stop active transfers continues
>> to remove USB requests from all dep lists, the newly added request will
>> also be removed, while controller still has an active TRB for it.
>> This can lead to the controller accessing an unmapped memory address.
>>
>> Fix this by ensuring parameters to prevent EP queuing are set before
>> calling the stop active transfers API.
>>
>> Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the 
>> controller")
>> Signed-off-by: Wesley Cheng 
>> ---
>> Changes since V1:
>>  - Added Fixes tag to point to the commit this is addressing
>>
>>  drivers/usb/dwc3/gadget.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 4780983..4d98fbf 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -783,8 +783,6 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
>>  
>>  trace_dwc3_gadget_ep_disable(dep);
>>  
>> -dwc3_remove_requests(dwc, dep);
>> -
>>  /* make sure HW endpoint isn't stalled */
>>  if (dep->flags & DWC3_EP_STALL)
>>  __dwc3_gadget_ep_set_halt(dep, 0, false);
>> @@ -803,6 +801,8 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
>>  dep->endpoint.desc = NULL;
>>  }
>>  
>> +dwc3_remove_requests(dwc, dep);
>> +
>>  return 0;
>>  }
>>  
>> @@ -1617,7 +1617,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
>> struct dwc3_request *req)
>>  {
>>  struct dwc3 *dwc = dep->dwc;
>>  
>> -if (!dep->endpoint.desc || !dwc->pullups_connected) {
>> +if (!dep->endpoint.desc || !dwc->pullups_connected || !dwc->connected) {
>>  dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
>>  dep->name);
>>  return -ESHUTDOWN;
>> @@ -2247,6 +2247,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
>> int is_on)
>>  if (!is_on) {
>>  u32 count;
>>  
>> +dwc->connected = false;
> 
> 
> You want to set this before __dwc3_gadget_stop() right? Then you may
> want to remove this same setting few lines below this. Otherwise, this
> looks good.
> 
> Thanks,
> Thinh
> 
Hi Thinh,

Ah, good catch, must've missed that while porting this over from my
local branch.  Will remove that connected false setting a few lines down.

Thanks
Wesley Cheng

> 
>>  /*
>>   * In the Synopsis DesignWare Cores USB3 Databook Rev. 3.30a
>>   * Section 4.1.8 Table 4-7, it states that for a 
>> device-initiated
>> @@ -3329,8 +3330,6 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 
>> *dwc)
>>  {
>>  u32 reg;
>>  
>> -dwc->connected = true;
>> -
>>  /*
>>   * WORKAROUND: DWC3 revisions <1.88a have an issue which
>>   * would cause a missing Disconnect Event if there's a
>> @@ -3370,6 +3369,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 
>> *dwc)
>>   * transfers."
>>   */
>>  dwc3_stop_active_transfers(dwc);
>> +dwc->connected = true;
>>  
>>  reg = dwc3_readl(dwc->regs, DWC3_DCTL);
>>  reg &= ~DWC3_DCTL_TSTCTRL_MASK;
>>
> 

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

[PATCH v2] usb: dwc3: gadget: Prevent EP queuing while stopping transfers

[Wesley Cheng]

In the situations where the DWC3 gadget stops active transfers, once
calling the dwc3_gadget_giveback(), there is a chance where a function
driver can queue a new USB request in between the time where the dwc3
lock has been released and re-aquired.  This occurs after we've already
issued an ENDXFER command.  When the stop active transfers continues
to remove USB requests from all dep lists, the newly added request will
also be removed, while controller still has an active TRB for it.
This can lead to the controller accessing an unmapped memory address.

Fix this by ensuring parameters to prevent EP queuing are set before
calling the stop active transfers API.

Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the 
controller")
Signed-off-by: Wesley Cheng 
---
Changes since V1:
 - Added Fixes tag to point to the commit this is addressing

 drivers/usb/dwc3/gadget.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4780983..4d98fbf 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -783,8 +783,6 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
 
trace_dwc3_gadget_ep_disable(dep);
 
-   dwc3_remove_requests(dwc, dep);
-
/* make sure HW endpoint isn't stalled */
if (dep->flags & DWC3_EP_STALL)
__dwc3_gadget_ep_set_halt(dep, 0, false);
@@ -803,6 +801,8 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
dep->endpoint.desc = NULL;
}
 
+   dwc3_remove_requests(dwc, dep);
+
return 0;
 }
 
@@ -1617,7 +1617,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
 {
struct dwc3 *dwc = dep->dwc;
 
-   if (!dep->endpoint.desc || !dwc->pullups_connected) {
+   if (!dep->endpoint.desc || !dwc->pullups_connected || !dwc->connected) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
dep->name);
return -ESHUTDOWN;
@@ -2247,6 +2247,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
if (!is_on) {
u32 count;
 
+   dwc->connected = false;
/*
 * In the Synopsis DesignWare Cores USB3 Databook Rev. 3.30a
 * Section 4.1.8 Table 4-7, it states that for a 
device-initiated
@@ -3329,8 +3330,6 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
 {
u32 reg;
 
-   dwc->connected = true;
-
/*
 * WORKAROUND: DWC3 revisions <1.88a have an issue which
 * would cause a missing Disconnect Event if there's a
@@ -3370,6 +3369,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
 * transfers."
 */
dwc3_stop_active_transfers(dwc);
+   dwc->connected = true;
 
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_TSTCTRL_MASK;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [android-porting] How to debug Android build in detailed.

[Wesley Emanuel Da Silva]

Em sex, 26 de fev de 2021 14:05, ghalib khan 
escreveu:

> Hello,
>
>  Am trying to build Android 10 with sources, i have noted the flow of
> build as follows,
>
> $ source ./build/envsetup.sh
>
> $ print_lunch_menu -  -> Lunch menu building on Linux
>
> $ lunch aosp_riscv64-eng
>
> $ m –j
>
> $ 
> /home/performance-server/ghalib-khan/android/t-head/aosp-riscv/aosp/build/soong/soong_ui.bash
>  --make-mode
> –j
>
> $ exec
> /home/performance-server/ghalib-khan/android/t-head/aosp-riscv/aosp/out/soong_ui
>  --make-mode
> –j
>
>
> As you see, i stucked at soong_ui --make-mode –j command,  can any one
> help me out to debug or know how the build was happening, if i want make
> any change in build sources so how can i do it.
>
> Please help out in soong build system in detailed.
>
>
> Thanks in advance,
>
> ghalib khan.
>
>
> --
> --
> unsubscribe: android-porting+unsubscr...@googlegroups.com
> website: http://groups.google.com/group/android-porting
>
> ---
> You received this message because you are subscribed to the Google Groups
> "android-porting" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-porting+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/android-porting/7a109d29-6186-4fcf-88c8-6e296c210ccen%40googlegroups.com
> 
> .
>

-- 
-- 
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting

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

[PATCH] usb: dwc3: gadget: Prevent EP queuing while stopping transfers

[Wesley Cheng]

In the situations where the DWC3 gadget stops active transfers, once
calling the dwc3_gadget_giveback(), there is a chance where a function
driver can queue a new USB request in between the time where the dwc3
lock has been released and re-aquired.  This occurs after we've already
issued an ENDXFER command.  When the stop active transfers continues
to remove USB requests from all dep lists, the newly added request will
also be removed, while controller still has an active TRB for it.
This can lead to the controller accessing an unmapped memory address.

Fix this by ensuring parameters to prevent EP queuing are set before
calling the stop active transfers API.

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

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4780983..4d98fbf 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -783,8 +783,6 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
 
trace_dwc3_gadget_ep_disable(dep);
 
-   dwc3_remove_requests(dwc, dep);
-
/* make sure HW endpoint isn't stalled */
if (dep->flags & DWC3_EP_STALL)
__dwc3_gadget_ep_set_halt(dep, 0, false);
@@ -803,6 +801,8 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
dep->endpoint.desc = NULL;
}
 
+   dwc3_remove_requests(dwc, dep);
+
return 0;
 }
 
@@ -1617,7 +1617,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
 {
struct dwc3 *dwc = dep->dwc;
 
-   if (!dep->endpoint.desc || !dwc->pullups_connected) {
+   if (!dep->endpoint.desc || !dwc->pullups_connected || !dwc->connected) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
dep->name);
return -ESHUTDOWN;
@@ -2247,6 +2247,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
if (!is_on) {
u32 count;
 
+   dwc->connected = false;
/*
 * In the Synopsis DesignWare Cores USB3 Databook Rev. 3.30a
 * Section 4.1.8 Table 4-7, it states that for a 
device-initiated
@@ -3329,8 +3330,6 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
 {
u32 reg;
 
-   dwc->connected = true;
-
/*
 * WORKAROUND: DWC3 revisions <1.88a have an issue which
 * would cause a missing Disconnect Event if there's a
@@ -3370,6 +3369,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
 * transfers."
 */
dwc3_stop_active_transfers(dwc);
+   dwc->connected = true;
 
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_TSTCTRL_MASK;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: Yara rule: how to detect unsupported PE file for Windows 10?

[Wesley Shields]

The string you are highlighting is not indicative of a file running on Windows 
10 or not. That string is in the DOS stub, which is executed when you try to 
run the program under DOS. Why this particular file is not running on your 
system is a different issue but it has nothing to do with that string. In fact, 
that particular string is common across all delphi language executables. One 
option to detect it is to share a hash of the file so people can inspect it and 
see what is really going on.

-- WXS

> On Mar 9, 2021, at 7:36 AM, Unknown  wrote:
> 
> I wonder is exist a rule for detecting damage, corrupted, unsupported binary 
> file by Windows Loader?
> 
> Sometimes a file can not be executed on Windows. 
> 
> 
> 
> Sometimes a file can not be run on Windows 10:
> 
> 
> 
> How do you think it can be done by Yara rule to detect such of broken, 
> unsupported files?
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/50d502d1-fae2-4e89-bca1-9309a85e103fn%40googlegroups.com
>  
> .
> 

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/4CD98139-8B8A-484E-B1A0-B6FC7217A3F5%40gmail.com.

Re: [PATCH v3 1/2] usb: dwc3: Trigger a GCTL soft reset when switching modes in DRD

[Wesley Cheng]

On 3/8/2021 7:05 PM, Thinh Nguyen wrote:
> Wesley Cheng wrote:
>>
>> On 3/6/2021 3:41 PM, Thinh Nguyen wrote:
>>> Wesley Cheng wrote:
>>>> On 1/8/2021 4:44 PM, Thinh Nguyen wrote:
>>>>> Hi,
>>>>>
>>>>> John Stultz wrote:
>>>>>> On Fri, Jan 8, 2021 at 4:26 AM Felipe Balbi  wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> John Stultz  writes:
>>>>>>>> From: Yu Chen 
>>>>>>>>
>>>>>>>> Just resending this, as discussion died out a bit and I'm not
>>>>>>>> sure how to make further progress. See here for debug data that
>>>>>>>> was requested last time around:
>>>>>>>>   
>>>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/lkml/calaqxlxdnaufjkx0an9xwwtfwvjmwigppy2aqsnj56yvnbu...@mail.gmail.com/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnsnlqd3w$
>>>>>>>>  
>>>>>>>>
>>>>>>>> With the current dwc3 code on the HiKey960 we often see the
>>>>>>>> COREIDLE flag get stuck off in __dwc3_gadget_start(), which
>>>>>>>> seems to prevent the reset irq and causes the USB gadget to
>>>>>>>> fail to initialize.
>>>>>>>>
>>>>>>>> We had seen occasional initialization failures with older
>>>>>>>> kernels but with recent 5.x era kernels it seemed to be becoming
>>>>>>>> much more common, so I dug back through some older trees and
>>>>>>>> realized I dropped this quirk from Yu Chen during upstreaming
>>>>>>>> as I couldn't provide a proper rational for it and it didn't
>>>>>>>> seem to be necessary. I now realize I was wrong.
>>>>>>>>
>>>>>>>> After resubmitting the quirk, Thinh Nguyen pointed out that it
>>>>>>>> shouldn't be a quirk at all and it is actually mentioned in the
>>>>>>>> programming guide that it should be done when switching modes
>>>>>>>> in DRD.
>>>>>>>>
>>>>>>>> So, to avoid these !COREIDLE lockups seen on HiKey960, this
>>>>>>>> patch issues GCTL soft reset when switching modes if the
>>>>>>>> controller is in DRD mode.
>>>>>>>>
>>>>>>>> Cc: Felipe Balbi 
>>>>>>>> Cc: Tejas Joglekar 
>>>>>>>> Cc: Yang Fei 
>>>>>>>> Cc: YongQin Liu 
>>>>>>>> Cc: Andrzej Pietrasiewicz 
>>>>>>>> Cc: Thinh Nguyen 
>>>>>>>> Cc: Jun Li 
>>>>>>>> Cc: Mauro Carvalho Chehab 
>>>>>>>> Cc: Greg Kroah-Hartman 
>>>>>>>> Cc: linux-...@vger.kernel.org
>>>>>>>> Signed-off-by: Yu Chen 
>>>>>>>> Signed-off-by: John Stultz 
>>>>>>>> ---
>>>>>>>> v2:
>>>>>>>> * Rework to always call the GCTL soft reset in DRD mode,
>>>>>>>>   rather then using a quirk as suggested by Thinh Nguyen
>>>>>>>>
>>>>>>>> v3:
>>>>>>>> * Move GCTL soft reset under the spinlock as suggested by
>>>>>>>>   Thinh Nguyen
>>>>>>> Because this is such an invasive change, I would prefer that we get
>>>>>>> Tested-By tags from a good fraction of the users before applying these
>>>>>>> two changes.
>>>>>> I'm happy to reach out to folks to try to get that. Though I'm
>>>>>> wondering if it would be better to put it behind a dts quirk flag, as
>>>>>> originally proposed?
>>>>>>
>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/lkml/20201021181803.79650-1-john.stu...@linaro.org/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnRWITZfc$
>>>>>>  
>>>>>>
>>>>>> That way folks can enable it for devices as they need?
>>>>>>
>>>>>> Again, I'm not trying to force this in as-is, just mostly sending it
>>>>>> out again for discussion to understand what other approach might work.
>>>>>>
>>>>>> thanks
>>>>>> -john
>>>>> A quirk would imply something is broken/diverged from the design right?
>>>>> But it's not the case here, and at least this is needed for HiKey960.
>>>>> Also, I think Rob will be ok with not adding 1 more quirk to the dwc3
>>>>> devicetree. :)
>>>>>
>>>>> BR,
>>>>> Thinh
>>>>>
>>>> Hi All,
>>>>
>>>> Sorry for jumping in, but I checked the SNPS v1.90a databook, and that
>>>> seemed to remove the requirement for the GCTL.softreset before writing
>>>> to PRTCAPDIR.  Should we consider adding a controller version/IP check?
>>>>
>>> Hi Wesley,
>>>
>>> From what I see in the v1.90a databook and others, the flow remains the
>>> same. I need to check internally, but I'm not aware of the change.
>>>
>> Hi Thinh,
>>
>> Hmmm, can you help check the register description for the PRTCAPDIR on
>> your v1.90a databook?  (Table 1-19 Fields for Register: GCTL (Continued)
>> Pg73)  When we compared the sequence in the description there to the
>> previous versions it removed the GCTL.softreset.  If it still shows up
>> on yours, then maybe my v1.90a isn't the final version?
>>
>> Thanks
>> Wesley Cheng
>>
> 
> Hi Wesley,
> 
> Actually your IP version type may use the newer flow. Can you print your
> DWC3_VER_TYPE? I still need to verify internally to know which versions
> need the update if any.
> 
> Thanks,
> Thinh
> 
Hi Thinh,

Sure, my DWC3_VER_TYPE output = 0x67612A2A

Thanks
Wesley Cheng

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

Re: [PATCH v3 1/2] usb: dwc3: Trigger a GCTL soft reset when switching modes in DRD

[Wesley Cheng]

On 3/6/2021 3:41 PM, Thinh Nguyen wrote:
> Wesley Cheng wrote:
>>
>> On 1/8/2021 4:44 PM, Thinh Nguyen wrote:
>>> Hi,
>>>
>>> John Stultz wrote:
>>>> On Fri, Jan 8, 2021 at 4:26 AM Felipe Balbi  wrote:
>>>>> Hi,
>>>>>
>>>>> John Stultz  writes:
>>>>>> From: Yu Chen 
>>>>>>
>>>>>> Just resending this, as discussion died out a bit and I'm not
>>>>>> sure how to make further progress. See here for debug data that
>>>>>> was requested last time around:
>>>>>>   
>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/lkml/calaqxlxdnaufjkx0an9xwwtfwvjmwigppy2aqsnj56yvnbu...@mail.gmail.com/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnsnlqd3w$
>>>>>>  
>>>>>>
>>>>>> With the current dwc3 code on the HiKey960 we often see the
>>>>>> COREIDLE flag get stuck off in __dwc3_gadget_start(), which
>>>>>> seems to prevent the reset irq and causes the USB gadget to
>>>>>> fail to initialize.
>>>>>>
>>>>>> We had seen occasional initialization failures with older
>>>>>> kernels but with recent 5.x era kernels it seemed to be becoming
>>>>>> much more common, so I dug back through some older trees and
>>>>>> realized I dropped this quirk from Yu Chen during upstreaming
>>>>>> as I couldn't provide a proper rational for it and it didn't
>>>>>> seem to be necessary. I now realize I was wrong.
>>>>>>
>>>>>> After resubmitting the quirk, Thinh Nguyen pointed out that it
>>>>>> shouldn't be a quirk at all and it is actually mentioned in the
>>>>>> programming guide that it should be done when switching modes
>>>>>> in DRD.
>>>>>>
>>>>>> So, to avoid these !COREIDLE lockups seen on HiKey960, this
>>>>>> patch issues GCTL soft reset when switching modes if the
>>>>>> controller is in DRD mode.
>>>>>>
>>>>>> Cc: Felipe Balbi 
>>>>>> Cc: Tejas Joglekar 
>>>>>> Cc: Yang Fei 
>>>>>> Cc: YongQin Liu 
>>>>>> Cc: Andrzej Pietrasiewicz 
>>>>>> Cc: Thinh Nguyen 
>>>>>> Cc: Jun Li 
>>>>>> Cc: Mauro Carvalho Chehab 
>>>>>> Cc: Greg Kroah-Hartman 
>>>>>> Cc: linux-...@vger.kernel.org
>>>>>> Signed-off-by: Yu Chen 
>>>>>> Signed-off-by: John Stultz 
>>>>>> ---
>>>>>> v2:
>>>>>> * Rework to always call the GCTL soft reset in DRD mode,
>>>>>>   rather then using a quirk as suggested by Thinh Nguyen
>>>>>>
>>>>>> v3:
>>>>>> * Move GCTL soft reset under the spinlock as suggested by
>>>>>>   Thinh Nguyen
>>>>> Because this is such an invasive change, I would prefer that we get
>>>>> Tested-By tags from a good fraction of the users before applying these
>>>>> two changes.
>>>> I'm happy to reach out to folks to try to get that. Though I'm
>>>> wondering if it would be better to put it behind a dts quirk flag, as
>>>> originally proposed?
>>>>
>>>> https://urldefense.com/v3/__https://lore.kernel.org/lkml/20201021181803.79650-1-john.stu...@linaro.org/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnRWITZfc$
>>>>  
>>>>
>>>> That way folks can enable it for devices as they need?
>>>>
>>>> Again, I'm not trying to force this in as-is, just mostly sending it
>>>> out again for discussion to understand what other approach might work.
>>>>
>>>> thanks
>>>> -john
>>> A quirk would imply something is broken/diverged from the design right?
>>> But it's not the case here, and at least this is needed for HiKey960.
>>> Also, I think Rob will be ok with not adding 1 more quirk to the dwc3
>>> devicetree. :)
>>>
>>> BR,
>>> Thinh
>>>
>> Hi All,
>>
>> Sorry for jumping in, but I checked the SNPS v1.90a databook, and that
>> seemed to remove the requirement for the GCTL.softreset before writing
>> to PRTCAPDIR.  Should we consider adding a controller version/IP check?
>>
> 
> Hi Wesley,
> 
> From what I see in the v1.90a databook and others, the flow remains the
> same. I need to check internally, but I'm not aware of the change.
> 
Hi Thinh,

Hmmm, can you help check the register description for the PRTCAPDIR on
your v1.90a databook?  (Table 1-19 Fields for Register: GCTL (Continued)
Pg73)  When we compared the sequence in the description there to the
previous versions it removed the GCTL.softreset.  If it still shows up
on yours, then maybe my v1.90a isn't the final version?

Thanks
Wesley Cheng

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

Re: [PATCH v3 1/2] usb: dwc3: Trigger a GCTL soft reset when switching modes in DRD

[Wesley Cheng]

On 1/8/2021 4:44 PM, Thinh Nguyen wrote:
> Hi,
> 
> John Stultz wrote:
>> On Fri, Jan 8, 2021 at 4:26 AM Felipe Balbi  wrote:
>>>
>>> Hi,
>>>
>>> John Stultz  writes:
>>>> From: Yu Chen 
>>>>
>>>> Just resending this, as discussion died out a bit and I'm not
>>>> sure how to make further progress. See here for debug data that
>>>> was requested last time around:
>>>>   
>>>> https://urldefense.com/v3/__https://lore.kernel.org/lkml/calaqxlxdnaufjkx0an9xwwtfwvjmwigppy2aqsnj56yvnbu...@mail.gmail.com/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnsnlqd3w$
>>>>  
>>>>
>>>> With the current dwc3 code on the HiKey960 we often see the
>>>> COREIDLE flag get stuck off in __dwc3_gadget_start(), which
>>>> seems to prevent the reset irq and causes the USB gadget to
>>>> fail to initialize.
>>>>
>>>> We had seen occasional initialization failures with older
>>>> kernels but with recent 5.x era kernels it seemed to be becoming
>>>> much more common, so I dug back through some older trees and
>>>> realized I dropped this quirk from Yu Chen during upstreaming
>>>> as I couldn't provide a proper rational for it and it didn't
>>>> seem to be necessary. I now realize I was wrong.
>>>>
>>>> After resubmitting the quirk, Thinh Nguyen pointed out that it
>>>> shouldn't be a quirk at all and it is actually mentioned in the
>>>> programming guide that it should be done when switching modes
>>>> in DRD.
>>>>
>>>> So, to avoid these !COREIDLE lockups seen on HiKey960, this
>>>> patch issues GCTL soft reset when switching modes if the
>>>> controller is in DRD mode.
>>>>
>>>> Cc: Felipe Balbi 
>>>> Cc: Tejas Joglekar 
>>>> Cc: Yang Fei 
>>>> Cc: YongQin Liu 
>>>> Cc: Andrzej Pietrasiewicz 
>>>> Cc: Thinh Nguyen 
>>>> Cc: Jun Li 
>>>> Cc: Mauro Carvalho Chehab 
>>>> Cc: Greg Kroah-Hartman 
>>>> Cc: linux-...@vger.kernel.org
>>>> Signed-off-by: Yu Chen 
>>>> Signed-off-by: John Stultz 
>>>> ---
>>>> v2:
>>>> * Rework to always call the GCTL soft reset in DRD mode,
>>>>   rather then using a quirk as suggested by Thinh Nguyen
>>>>
>>>> v3:
>>>> * Move GCTL soft reset under the spinlock as suggested by
>>>>   Thinh Nguyen
>>> Because this is such an invasive change, I would prefer that we get
>>> Tested-By tags from a good fraction of the users before applying these
>>> two changes.
>> I'm happy to reach out to folks to try to get that. Though I'm
>> wondering if it would be better to put it behind a dts quirk flag, as
>> originally proposed?
>>
>> https://urldefense.com/v3/__https://lore.kernel.org/lkml/20201021181803.79650-1-john.stu...@linaro.org/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnRWITZfc$
>>  
>>
>> That way folks can enable it for devices as they need?
>>
>> Again, I'm not trying to force this in as-is, just mostly sending it
>> out again for discussion to understand what other approach might work.
>>
>> thanks
>> -john
> 
> A quirk would imply something is broken/diverged from the design right?
> But it's not the case here, and at least this is needed for HiKey960.
> Also, I think Rob will be ok with not adding 1 more quirk to the dwc3
> devicetree. :)
> 
> BR,
> Thinh
> 

Hi All,

Sorry for jumping in, but I checked the SNPS v1.90a databook, and that
seemed to remove the requirement for the GCTL.softreset before writing
to PRTCAPDIR.  Should we consider adding a controller version/IP check?

Thanks
Wesley Cheng

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

Re: [PATCH v3 2/2] usb: dwc3: Fix DRD mode change sequence following programming guide

[Wesley Cheng]

On 1/7/2021 5:51 PM, John Stultz wrote:
> In reviewing the previous patch, Thinh Nguyen pointed out that
> the DRD mode change sequence should be like the following when
> switching from host -> device according to the programming guide
> (for all DRD IPs):
> 1. Reset controller with GCTL.CoreSoftReset
> 2. Set GCTL.PrtCapDir(device)
> 3. Soft reset with DCTL.CSftRst
> 4. Then follow up with the initializing registers sequence
> 
> The current code does:
> a. Soft reset with DCTL.CSftRst on driver probe
> b. Reset controller with GCTL.CoreSoftReset (added in previous
>patch)
> c. Set GCTL.PrtCapDir(device)
> d. < missing DCTL.CSftRst >
> e. Then follow up with initializing registers sequence
> 
> So this patch adds the DCTL.CSftRst soft reset that was currently
> missing from the dwc3 mode switching.
> 
> Cc: Felipe Balbi 
> Cc: Tejas Joglekar 
> Cc: Yang Fei 
> Cc: YongQin Liu 
> Cc: Andrzej Pietrasiewicz 
> Cc: Thinh Nguyen 
> Cc: Jun Li 
> Cc: Mauro Carvalho Chehab 
> Cc: Greg Kroah-Hartman 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: John Stultz 
> ---
> Feedback would be appreciated. I'm a little worried I should be
> conditionalizing the DCTL.CSftRst on DRD mode controllers, but
> I'm really not sure what the right thing to do is for non-DRD
> mode controllers.
> ---
>  drivers/usb/dwc3/core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index b6a6b90eb2d5..71f8b07ecb99 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -40,6 +40,8 @@
>  
>  #define DWC3_DEFAULT_AUTOSUSPEND_DELAY   5000 /* ms */
>  
> +static int dwc3_core_soft_reset(struct dwc3 *dwc);
> +
>  /**
>   * dwc3_get_dr_mode - Validates and sets dr_mode
>   * @dwc: pointer to our context structure
> @@ -177,6 +179,7 @@ static void __dwc3_set_mode(struct work_struct *work)
>  
>   dwc3_set_prtcap(dwc, dwc->desired_dr_role);
>  
> + dwc3_core_soft_reset(dwc);

Hi John/Thinh/Felipe,

I actually added this change into my local branch, because we were
seeing an issue when switching from host mode --> peripheral mode.  What
was happening was that the RXFIFO register did not update back to the
expected value for peripheral mode by the time
dwc3_gadget_init_out_endpoint() was executed.  With the logic to
calculate the EP max packet limit based on RXFIFO reg, this caused all
EPs to be set with an EP max limit of 0.

With this change, it seemed to help with the above issue.  However, can
we consider moving the core soft reset outside the spinlock?  At least
with our PHY init routines, we have some msleep() calls for waiting for
the PHYs to be ready, which will end up as a sleeping while atomic bug.
(not sure if PHY init is required to be called in atomic context)

Thanks
Wesley Cheng

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

Re: [ANNOUNCE] Apache BookKeeper 4.13.0 released

[Wesley Peng]

great to hear that. thank you.


On 26.02.2021 04:00, Andrey Yegorov wrote:

The Apache BookKeeper team is proud to announce Apache BookKeeper
version
4.13.0.

Apache BookKeeper is a scalable, fault-tolerant, and low-latency
storage service optimized for
real-time workloads. It has been used as a fundamental service to
build reliable services.
It is also the log segment store for Apache DistributedLog and the
message store for Apache Pulsar.

This is the 25th release of the Apache BookKeeper.

Release 4.13.0 improves the reliability of the Stream Storage, brings
additional configuration options for the Stream Storage and Prometheus
HTTP Server, fixes multiple bugs, and brings critical dependencies
up-to-date.

For BookKeeper release details and downloads, visit:

https://bookkeeper.apache.org/releases/

BookKeeper 4.13.0 Release Notes are at:

https://bookkeeper.apache.org/docs/4.13.0/overview/releaseNotes/

We would like to thank the contributors that made the release
possible.

Regards,
The BookKeeper Team

Re: [Mpi-forum] problems pushing to your fork of mpi-standard

[Wesley Bland via mpi-forum]

I think GitHub is having problems right now. 

https://www.githubstatus.com/

Let’s give that a little time to go green again and then see if we still have 
trouble. 

> On Feb 24, 2021, at 1:44 PM, Pritchard Jr., Howard via mpi-forum 
>  wrote:
> 
> 
> Hi Folks,
>  
> I think we’ve run over some GitHub private repo limits.  Neither Dan nor I 
> can push/pull to/from either our mpiwg-sessions fork of the mpi-standard or 
> forks into our personnel projects spaces.
> We recently invited another member to our WG sessions Github group and are 
> suspicious we’ve gone over some kind of limit.
>  
> Wesley could you check this out? 
>  
> At this point I can no longer update my PRs against the mpi-standard since I 
> can’t push to my fork of the mpi-standard.
>  
> Could others check this?
>  
> Thanks,
>  
> Howard
>  
> -- 
>  
> Howard Pritchard
> HPC-ENV
> Los Alamos National Laboratory
>  
> ___
> 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

Re: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan

[Wesley Bland via mpi-forum]

It seems like Martin covered all of the points I was going to mention. I’d 
summarize by saying that I believe we’re following the rules as written. I also 
believe that we’re giving the rules a bit of abuse here because of the volume 
of changes coming in at the last minute.

That being said, I think the volume of changes is actually a good thing. This 
is the first time we’re ratifying the MPI Standard since moving from SVN to 
Git/GitHub and doing so has made the process more transparent and easier for 
people to catch these sorts of small issues that we’re discussing now. All of 
being at home has potentially also given us more time over the last few months 
to find each of these issues.

I freely expect and admit that I’ve probably missed a PR or two as I’ve been 
trying to keep up. Hopefully we’ve found them all now (thanks to those who have 
pointed me to some of those that I missed).

If we do end up having another FRM, I agree that it gives us one more 
opportunity to give the entire document a read-through. I don’t think we’ll do 
another pass like we did before the December meeting, but we should certainly 
have the CCs look through it. However, when doing so, remember that we’ll have 
to accept some level of imperfection. The document has been imperfect for a 
long time and will continue to be so in the future. We have to look at the list 
of issues that we know about and decide which ones we can live with and for 
which ones we’re willing to delay publishing MPI 4.0. It’s especially important 
to be cognizant of the procedures that we’ve chosen for ourselves when doing 
this and to avoid making more and more exceptions just to get “one more thing” 
into the document. Every time someone suggests that we should “just make this 
change" to improve the text, you should think “just make this change” == “delay 
MPI 4.0 for another meeting or more”.

Thanks,
Wes

> On Feb 23, 2021, at 4:30 AM, Martin Schulz via mpi-forum 
> mailto:mpi-forum@lists.mpi-forum.org>> wrote:
> 
> Hi Rolf,
> 
> Comments inline marked with ">>"
> 
> Martin
> 
> 
> -- 
> Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems
> Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching
> Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ)
> Email: schu...@in.tum.de <mailto:schu...@in.tum.de>
> 
> 
> 
> On 23.02.21, 09:53, "mpi-forum on behalf of Rolf Rabenseifner via mpi-forum" 
>  <mailto:mpi-forum-boun...@lists.mpi-forum.org> on behalf of 
> mpi-forum@lists.mpi-forum.org <mailto:mpi-forum@lists.mpi-forum.org>> wrote:
> 
>Dear Wesley and all,
> 
>Wesley, you did yesterday a wonderful job. 
>Please do not take the following items as any critism on your work.
>they are only on procedural/general problems we may have.
> 
>1. Can it be that one No-No-vote can influence the outcome of the MPI 
>   standard when the majority does not see a problem with the text?  
> 
>>> Yes, that is correct - if a No-No fails, then we vote on whether to advance 
>>> the standard without that PR.
> 
>   We may procedurally gave and still give no-no-voters to much 
>   influence on the text.
> 
>>> To some degree, yes, but this is supposed to be a last stop-gap measure and 
>>> then we do, of course, folks to act reasonable with the consequences, which 
>>> - so far - has worked IHMO.
> 
>   I hope that this 
>- will not happen during this meeting
> 
>>> To be honest, I wouldn't be surprised if it did, and probably not without 
>>> reason.
> 
>- and if it happens then I hope that the FRM is changed to a RC
> 
>>> That's why we will have that vote on a different day - when we vote on the 
>>> whole standard, everyone will have seen what had been voted in and what out 
>>> and has the ability to vote accordingly. Personally, I hope as well that, 
>>> if we find problems and we reject additions that are impactful, that a 
>>> majority would vote for another round for the FRM.
> 
>- and therefore the exactly same PR is then voted with a normal
>  erata-vote into the standard on the next meeting.
> 
>>> That is technically correct, but I would hope that we can fix issue that 
>>> are brought up so that the concerns of the few no/no votes are met after 
>>> the changes. Note that we do not have to fix them this week (would be good 
>>> if we do, but not required), but we need to add them to the list of fixes 
>>> needed. So far, from the issues that are noted on the list, I would think 
>>> that we can achieve agreement on all of them before June. We'll see - I am 

modperl vs fastcgi

[Wesley Peng]

Do you anybody have a comparison for modperl vs fastcgi?
For both the performance and convenience of development/deployment.

Thank you.

Re: [CFP] ApacheCon Asia about API/mrico service

[Wesley Peng]

nice to know it. thanks.

On 23.02.2021 09:02, Ming Wen wrote:

hello, dev,
The ApacheCon Asia started CFP[1],
and everyone is welcome to submit topics related to Apache APISIX.
Both Mandarin and English are fine. Looking forward to it.

[1] acasia2021.jamhosted.net 

Thanks,
Ming Wen, Apache APISIX PMC Chair
Twitter: _WenMing

Re: Learning YARA - hashes not being recognized?

[Wesley Shields]

This is a decision made by YARA. The underlying code which is doing the hashing 
is OpenSSL and that outputs using lowercase. Even if we switched it to all be 
uppercase we would have users complaining that they are expecting lowercase. We 
can't please everyone, so we just have to pick one and stick to it.

-- WXS

> On Feb 22, 2021, at 11:53 AM, Jonathan Livolsi  wrote:
> 
> Hi,
> 
> Ok, so because every hashing algorithm returns hashes in all uppercase and 
> yara requires all lower case, the only solution is for the user to manually 
> go through and change all uppercase to lowercase in the hash rather than have 
> either a tolower() functionality added to the yara rules or allow yara to 
> recognize both upper and lower case characters?  I feel like the industry 
> accepted standard for all hashing algorithms is that they are always in 
> uppercase and that should be expected, not the other way around.  I mean my 
> years of being a developer supports that gut feeling.  I am genuinely 
> confused by this decision to only accept lowercase and not upper for hashes.  
> Is this a virustotal issue or just a decision in the programming for yara?
> 
> 
> Jonathan
> 
> On Mon, Feb 22, 2021 at 11:33 AM Wesley Shields  <mailto:w...@atarininja.org>> wrote:
> See the warning at the top of 
> https://yara.readthedocs.io/en/stable/modules/hash.html 
> <https://yara.readthedocs.io/en/stable/modules/hash.html> - all hashes are 
> returned in lowercase.
> 
> -- WXS
> 
>> On Feb 22, 2021, at 11:30 AM, Jonathan Livolsi > <mailto:jlivo...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> I am going through a lab to learn yara rules and have a simple problem but I 
>> am not seeing why this might be happening.  It is an online course and their 
>> support doesn't help with this kind of stuff.  I am just writing a simple 
>> rule to check the MZ bits and the file hash for MD5, SHA1, and SHA256.  
>> Nothing complicated about it.
>> 
>> In this screenshot I have in my simple yara rule a check for the first bytes 
>> of 5A4D and it works fine.  I commented out the hash checks and in the 
>> console you can see that I get a 1 returned because the rule matched.  
>> 
>> 
>> In this screenshot I uncommented the hash checks and the rule fails to 
>> match.  If I comment out the strings and the check in the conditions but 
>> leave in the hash (even just one at a time) the rule does not ever match.  
>> Yet in the powershell prompt to the right I have the calculated hashed that 
>> I used in the rule.  Am I missing something?
>> 
>> 
>> Thanks for the help.
>> 
>> 
>> Jonathan
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "YARA" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to yara-project+unsubscr...@googlegroups.com 
>> <mailto:yara-project+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/yara-project/CACYKFWr7-UYXkMr1jDQMaFOBMm6%2BTq7Av-VfdBCgCgNoyS7q_g%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/yara-project/CACYKFWr7-UYXkMr1jDQMaFOBMm6%2BTq7Av-VfdBCgCgNoyS7q_g%40mail.gmail.com?utm_medium=email_source=footer>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> <mailto:yara-project+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/16F6BF7C-921A-4B74-902C-5772C0687947%40atarininja.org
>  
> <https://groups.google.com/d/msgid/yara-project/16F6BF7C-921A-4B74-902C-5772C0687947%40atarininja.org?utm_medium=email_source=footer>.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> <mailto:yara-project+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/CACYKFWoSshZ9m8%3DX2pT-f4S_sZpDTabdKCwk%2BTRCS3ngWSW34Q%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/yara-project/CACYKFWoSshZ9m8%3DX2pT-f4S_sZpDTabdKCwk%2BTRCS3ngWSW34Q%40mail.gmail.com?utm_medium=email_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/A63BBAF6-39ED-4215-B5C0-3CD069884922%40gmail.com.

Re: Learning YARA - hashes not being recognized?

[Wesley Shields]

See the warning at the top of 
https://yara.readthedocs.io/en/stable/modules/hash.html - all hashes are 
returned in lowercase.

-- WXS

> On Feb 22, 2021, at 11:30 AM, Jonathan Livolsi  wrote:
> 
> Hi,
> 
> I am going through a lab to learn yara rules and have a simple problem but I 
> am not seeing why this might be happening.  It is an online course and their 
> support doesn't help with this kind of stuff.  I am just writing a simple 
> rule to check the MZ bits and the file hash for MD5, SHA1, and SHA256.  
> Nothing complicated about it.
> 
> In this screenshot I have in my simple yara rule a check for the first bytes 
> of 5A4D and it works fine.  I commented out the hash checks and in the 
> console you can see that I get a 1 returned because the rule matched.  
> 
> 
> In this screenshot I uncommented the hash checks and the rule fails to match. 
>  If I comment out the strings and the check in the conditions but leave in 
> the hash (even just one at a time) the rule does not ever match.  Yet in the 
> powershell prompt to the right I have the calculated hashed that I used in 
> the rule.  Am I missing something?
> 
> 
> Thanks for the help.
> 
> 
> Jonathan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/CACYKFWr7-UYXkMr1jDQMaFOBMm6%2BTq7Av-VfdBCgCgNoyS7q_g%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/16F6BF7C-921A-4B74-902C-5772C0687947%40atarininja.org.

RE:[cayugabirds-l] Dead birds under the thistle feeder

[Wesley M. Hochachka]

If the dead birds were siskins, redpolls, or goldfinches, my first reaction is 
that the birds died from salmonellosis, and potentially you might have observed 
these birds sitting motionless and incredibly puffed up near the bird feeder at 
some point before you found the dead bird on the ground.

Salmonellosis outbreaks, which particularly hit siskins and redpolls, are an 
unfortunately predictable corollary of irruptions of these species.  Taking 
down your thistle feeder to disperse the birds might reduce further 
transmission, but it's hard to tell because the birds could just start 
congregating (maybe in larger numbers) at some other bird feeder in the area.

Wesley Hochachka




-Original Message-
From: bounce-125406737-3494...@list.cornell.edu 
 On Behalf Of Patrizia Sione
Sent: Monday, February 22, 2021 9:30 AM
To: CAYUGABIRDS-L 
Subject: [cayugabirds-l] Dead birds under the thistle feeder

Hello all,

In the course of the past 10 days, we have discovered a dead bird under a 
feeder in three separate occasions, the latest this morning.  No apparent 
injury.  The thistle is fresh (it goes pretty quickly) and we keep the feeders 
clean and sanitized. We called the Cornell hospital but they did not accept our 
request to have a necropsy conducted on the birds (we kept two of them in a 
sealed freezer bag  outside).  We have decals and nets outside our windows to 
prevent birds from hitting them.  

Any ideas about what could be causing this and how to prevent it from happening 
again?  It is the first time it has ever happened to us in the 10 years we’ve 
lived in our present location, and all this time we’ve fed birds.

Many thanks,
Patrizia Sione



--

Cayugabirds-L List Info:
http://www.NortheastBirding.com/CayugabirdsWELCOME
http://www.NortheastBirding.com/CayugabirdsRULES
http://www.NortheastBirding.com/CayugabirdsSubscribeConfigurationLeave.htm

ARCHIVES:
1) http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html
2) http://www.surfbirds.com/birdingmail/Group/Cayugabirds
3) http://birdingonthe.net/mailinglists/CAYU.html

Please submit your observations to eBird:
http://ebird.org/content/ebird/

--

--

Cayugabirds-L List Info:
http://www.NortheastBirding.com/CayugabirdsWELCOME
http://www.NortheastBirding.com/CayugabirdsRULES
http://www.NortheastBirding.com/CayugabirdsSubscribeConfigurationLeave.htm

ARCHIVES:
1) http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html
2) http://www.surfbirds.com/birdingmail/Group/Cayugabirds
3) http://birdingonthe.net/mailinglists/CAYU.html

Please submit your observations to eBird:
http://ebird.org/content/ebird/

--

Re: master deps error【20210219】

[Wesley Peng]

QQ MIME sucks. please use a standard email product such as Gmail.


On Fri, Feb 19, 2021, at 9:37 AM, 15717900 wrote:
> hello,
>I use Tencent virtual machine to compile the master 
> version.
>the error message is
> 
> 
> ---this is err 
> begin---
>inflating: luasocket-3.0-rc1/test/udpconnectsrvr.lua
>  inflating: luasocket-3.0-rc1/test/unixclnt.lua
>  inflating: luasocket-3.0-rc1/test/unixsrvr.lua
>  inflating: luasocket-3.0-rc1/test/upload.html
>  inflating: luasocket-3.0-rc1/test/urltest.lua
>  inflating: luasocket-3.0-rc1/test/utestclnt.lua
>  inflating: luasocket-3.0-rc1/test/utestsrvr.lua
>  inflating: luasocket-3.0-rc1/win32.cmd
> gcc -O2 -fPIC -I/usr/include -c src/mime.c -o src/mime.o 
> -DLUA_COMPAT_APIINTCASTS -DLUASOCKET_DEBUG 
> -DLUASOCKET_API=__attribute__((visibility("default"))) -D   
>
>
> 
> UNIX_API=__attribute__((visibility("default"))) 
> -DMIME_API=__attribute__((visibility("default")))
> src/mime.c:7:17: fatal error: lua.h: No such file or directory
> #include "lua.h"
> ^
> compilation terminated.
> 
> 
> Error: Failed installing dependency: 
> https://luarocks.org/luasec-0.9-1.src.rock - Failed installing dependency: 
> https://luarocks.org/luasocket-3.0rc1-2.src.r;
>
>
>ock - Build error: Failed 
> compiling object src/mime.o
> make: *** [deps] Error 1
> ---this is err end---
> （1）openresty -v（Both versions have the same error message）
> nginx version: openresty/1.19.3.1
> nginx version: openresty/1.17.8.2
> openssl-1.1.1g
> 
> （2）lua -v
> Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> 
> 
> 
> （3）luarocks
> LuaRocks 2.3.0, a module deployment system for Lua
> 
> 
> 
> （4）uname -a
> Linux VM-0-14-centos 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> 
> Looking forward to answer，thanks

[Mpi-forum] Feb 2021 MPI Forum Meeting Plan

[Wesley Bland via mpi-forum]

Hi all,

I wanted to give an update on the plan for the meeting next week after our 
virtual meeting yesterday.

The original plan for the Feb 2021 meeting was to be a Final Ratification 
Meeting (FRM), which would mean that at some point during the meeting, we would 
potentially ratify MPI 4.0 and elect officers for the next release of the MPI 
Standard. The rules for that are in our procedures document on our website and 
it turns out they handle our current situation very well. The relevant pieces 
are this:

At the last meeting, we made two lists of items that were not yet fixed. These 
lists are maintained on agenda and voting page for the meeting: 
https://www.mpi-forum.org/meetings/2021/02/votes 
 
The items that we knew about by the end of the December 2020 meeting - 
Everything on this list that was fixed will be voted on using the same rules as 
an errata vote.
The items that were discovered after the end of the December 2020 meeting - 
Everything on this list that was fixed will be voted on using the same rules as 
a no-no vote.
We will construct another list during the February 2021 meeting to keep track 
of remaining issues that we see with the document. This list is in the same 
place as where we tracked the previous work: 
https://github.com/mpi-forum/mpi-issues/projects/2 
 
On a separate day from the items in #1 above, we will have a ballot to decide 
whether the remaining issues should cause us to delay ratifying MPI 4.0.
Without attempting to editorialize too much (people may vote in whatever way 
they think is most appropriate), based on the conversations in the virtual 
meeting yesterday, I would expect this ballot to pass. The ramifications of 
that are below.
If the ballot in #3 fails (saying the list of remaining items is not blocking 
MPI 4.0), then we hold another ballot to ratify MPI 4.0.
If the ballot in #3 passes (saying the list should block MPI 4.0), then the 
February 2021 meeting essentially becomes a Release Candidate Meeting (RCM) 
like our December 2020 meeting. This means:
The June 2021 meeting becomes the new FRM meeting for MPI 4.0
The remaining items list becomes the “errata” list for the June meeting and 
everything remaining on it should be addressed ASAP to allow time to discuss, 
merge, and generate a new release candidate document for that meeting 
(tentative deadline for PRs to be created would be April 19th, but they should 
be created and hopefully merged long before that to avoid similar problems for 
the next meeting).
Any new items that are discovered before the next meeting can still be added to 
the second list for a no-no vote.
A new chapter-by-chapter reading is not necessary or required.
Officer nominations will reopen and we will hold elections at the June meeting.

If we do decide to delay MPI 4.0, I don’t think the intention is to “open the 
floodgates” for every small thing we’ve noticed is wrong in the document. As 
Bill has said, we’ll never fix every little thing, so right now let’s focus on 
the major issues that would cause problems and keep doing the rest for MPI 4.1. 
If there are remaining issues from the previous lists that we’d like to 
address, go ahead and create the PR for them and we can make a decision later 
on whether to vote it into MPI 4.0 or 4.1. Either way, the PR will be useful.

In order to get through all of the things above and still have time to discuss 
the remaining technical issues, we’re going to have to be very aggressive in 
our timeline for reading all of the changes since the last meeting. As you can 
see on the votes page, we have 76 issues to be read. In an effort to get those 
done as quickly as possible, Martin and I will be going through the issues/PRs 
and asking for input from others as we go (but avoiding context switching from 
laptop to laptop between each issue). We hope this will give us time to finish 
the entire set of issues on day one or two.

If there are items that begin to have prolonged technical discussion, we will 
take that as a sign that the issue needs more discussion with the relevant 
groups outside of the full-forum meeting time, which is very limited. The 
interested parties should schedule a separate time to have those discussions 
and bring the results back in a future virtual meeting over the next month or 
two.

If you haven’t registered for the meeting for next week, please do so now on 
the logistics page: https://www.mpi-forum.org/meetings/2021/02/logistics 
 I’ll be updating the 
attendance page periodically, but keep in mind that the process is manual so it 
doesn’t happen immediately.

That’s all from me for now. I think Martin had some more thoughts about what to 
do with the remaining technical items that he’ll address in another email.

Thanks,
Wes___
mpi-forum mailing list

Re: [PATCH v7 4/5] usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default

[Wesley Cheng]

On 2/2/2021 8:23 AM, Bjorn Andersson wrote:
> On Thu 28 Jan 22:46 CST 2021, Wesley Cheng wrote:
> 
>> In order to take advantage of the TX fifo resizing logic, manually add
>> these properties to the DWC3 child node by default.  This will allow
>> the DWC3 gadget to resize the TX fifos for the IN endpoints, which
>> help with performance.
>>
>> Signed-off-by: Wesley Cheng 
>> ---
>>  drivers/usb/dwc3/dwc3-qcom.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
>> index d803ee9..4ea6be3 100644
>> --- a/drivers/usb/dwc3/dwc3-qcom.c
>> +++ b/drivers/usb/dwc3/dwc3-qcom.c
>> @@ -564,6 +564,7 @@ static int dwc3_qcom_clk_init(struct dwc3_qcom *qcom, 
>> int count)
>>  
>>  static const struct property_entry dwc3_qcom_acpi_properties[] = {
>>  PROPERTY_ENTRY_STRING("dr_mode", "host"),
>> +PROPERTY_ENTRY_BOOL("tx-fifo-resize"),
> 
> I checked the ACPI tables for Lenovo Miix 630, Yoga C630 and Flex 5G and
> neither one has this property specified. So while we could just add this
> here, it would have to be done in collaboration with the people who
> actually define these. And as said before, I believe we want this to
> always be enabled.
> 
>>  {}
>>  };
>>  
>> @@ -634,6 +635,7 @@ static int dwc3_qcom_of_register_core(struct 
>> platform_device *pdev)
>>  struct dwc3_qcom*qcom = platform_get_drvdata(pdev);
>>  struct device_node  *np = pdev->dev.of_node, *dwc3_np;
>>  struct device   *dev = >dev;
>> +struct property *prop;
>>  int ret;
>>  
>>  dwc3_np = of_get_child_by_name(np, "dwc3");
>> @@ -642,6 +644,14 @@ static int dwc3_qcom_of_register_core(struct 
>> platform_device *pdev)
>>  return -ENODEV;
>>  }
>>  
>> +prop = kzalloc(sizeof(*prop), GFP_KERNEL);
>> +if (prop) {
>> +prop->name = "tx-fifo-resize";
>> +ret = of_add_property(dwc3_np, prop);
> 
> Can't we come up with a way where the platform driver enables this on
> the core driver without modifying DT?
> 
> Regards,
> Bjorn

Hi Bjorn,

Sorry for the late response.  As you know, its a little difficult to
access the DWC3 core device during DWC3 qcom probe time, as the DWC3
core will likely return deferred probe due to the PHY devices not being
ready.

This is why I went with the approach to modify the DWC3 node here, so
that when the DWC3 core is eventually probed, it wouldn't miss this
property setting.  If I tried to set this dynamically, say in
dwc3_qcom_vbus_override() (with proper NULL checks), then I'd miss this
setting for the first enumeration, but if cable plug out/in logic is
present, the setting would kick in on subsequent cable events.

Thanks
Wesley Cheng

> 
>> +if (ret < 0)
>> +dev_info(dev, "unable to add tx-fifo-resize prop\n");
>> +}
>> +
>>  ret = of_platform_populate(np, NULL, NULL, dev);
>>  if (ret) {
>>  dev_err(dev, "failed to register dwc3 core - %d\n", ret);
>> -- 
>> 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

Re: usb: dwc3: gadget: Change runtime pm function for DWC3 runtime suspend

[Wesley Cheng]

On 2/15/2021 5:30 PM, Jung Daehwan wrote:
> Hello, Alan
> 
> On Mon, Feb 15, 2021 at 12:41:45PM -0500, Alan Stern wrote:
>> On Mon, Feb 15, 2021 at 11:38:58AM +0900, Daehwan Jung wrote:
>>> It seems pm_runtime_put calls runtime_idle callback not runtime_suspend 
>>> callback.
>>
>> How is this fact related to your patch?
> 
> I think we should cause dwc3_runtime_suspend at the time.
> That's why I use pm_runtime_put_sync_suspend.
> 
>>
>>> It's better to use pm_runtime_put_sync_suspend to allow DWC3 runtime 
>>> suspend.
>>
>> Why do you think it is better?  The advantage of pm_runtime_put is that 
>> it allows the suspend to occur at a later time in a workqueue thread, so 
>> the caller doesn't have to wait for the device to go into suspend.
>>
> 
> We can assume DWC3 was already in suspend state if pm_runtime_get_sync
> returns 0. DWC3 resumes due to pm_rumtime_get_sync but it doesn't
> re-enter runtime_suspend but runtime_idle. pm_runtime_put decreases
> usage_count but doesn't cause runtime_suspend.
> 
> 1. USB disconnected
> 2. UDC unbinded
> 3. DWC3 runtime suspend
> 4. UDC binded unexpectedly
> 5. DWC3 runtime resume (pm_runtime_get_sync)
> 6. DWC3 runtime idle (pm_runtime_put)
>-> DWC3 runtime suspend again (pm_runtime_put_sync_suspend)
> 
> I've talked with Wesley in other patch.
> 
> usbb: dwc3: gadget: skip pullup and set_speed after suspend
> patchwork.kernel.org/project/linux-usb/patch/163968-102424-1-git-send-email-dh10.j...@samsung.com
> 
> @ Wesley
> 
> I think We should guarantee DWC3 enters suspend again at the time.
> How do you think?
> 
Hi Daehwan,

Even if we call runtime idle versus suspend, if the device is still in
the disconnected state, it should call the runtime PM suspend routine
after the autosuspend timer expires.  As Alan mentioned already, this
allows not blocking the caller for the entire DWC3 suspend sequence to
execute. (DWC3 core will suspend other components as well, such as PHYs)

Also, for legitimate cases where pullup is actually called to start
enumeration from a suspended state, I'm not sure if the short duration
between RS set and re-suspend (due to your patch) is enough time for the
host to actually detect the device connected.

Thanks
Wesley Cheng

> Best Regards,
> Jung Daehwan
> 
>> Alan Stern
>>
> 
> 
>>> Signed-off-by: Daehwan Jung 
>>> ---
>>>  drivers/usb/dwc3/gadget.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index aebcf8e..4a4b93b 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -2229,7 +2229,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
>>> int is_on)
>>>  */
>>> ret = pm_runtime_get_sync(dwc->dev);
>>> if (!ret || ret < 0) {
>>> -   pm_runtime_put(dwc->dev);
>>> +   pm_runtime_put_sync_suspend(dwc->dev);
>>> return 0;
>>> }
>>>  
>>> -- 
>>> 2.7.4
>>>
>>
>>

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

Re: [plonegov-br] Erro ao tentar instalar Portal

[Wesley Lopes]

Joaby,

parece que você não pinou ftw.upgrade = 3.0.0, ou pinou em algum arquivo
errado. Sua pinagem não está fazendo efeito.

Em seg., 15 de fev. de 2021 às 10:33, Joaby Augusto <
joabyaugu...@hotmail.com> escreveu:

> Olá bom dia wesley,
>
> Version and requirements information containing six:
>
>   [versions] constraint on six: 1.10.0
>
>   Requirement of brasil.gov.portal==2.1.1: six
>
>   Requirement of z3c.form: six
>
>   Requirement of plone.contentrules: six
>
>   Requirement of plone.api: six
>
>   Requirement of collective.fingerpointing: six
>
>   Requirement of collective.cover: six
>
>   Requirement of brasil.gov.tiles: six
>
>   Requirement of brasil.gov.agenda: six
>
>   Requirement of Products.CMFQuickInstallerTool: six
>
>   Requirement of plone.app.textfield: six
>
>   Requirement of plone.transformchain: six
>
>   Requirement of plone.folder: six
>
>   Requirement of Products.CMFDynamicViewFTI: six
>
>   Requirement of plone.subrequest: six
>
>   Requirement of diazo>=1.0.3: six
>
>   Requirement of z3c.pt>=2.2: six
>
>   Requirement of ftw.upgrade: six>=1.12.0
>
> While:
>
>   Installing instance.
>
> Error: The requirement ('six>=1.12.0') is not allowed by your [versions]
> constraint (1.10.0)
>
>
>  Continua o mesmo erro!
> --
> *De:* Joaby Augusto 
> *Enviado:* segunda-feira, 8 de fevereiro de 2021 22:37
> *Para:* Comunidade Plone no Governo 
> *Assunto:* RE: [plonegov-br] Erro ao tentar instalar Portal
>
> Olá Wesley,
>
> Fiz o procedimento que você mencionou, mais sem êxito.
>
> Infelizmente o erro persiste.
> --
> *De:* plonegov-br-boun...@listas.interlegis.gov.br <
> plonegov-br-boun...@listas.interlegis.gov.br> em nome de Wesley Lopes <
> wesle...@gmail.com>
> *Enviado:* segunda-feira, 8 de fevereiro de 2021 21:29
> *Para:* Comunidade Plone no Governo 
> *Assunto:* Re: [plonegov-br] Erro ao tentar instalar Portal
>
> Olá Joaby!
>
> Você pode tentar pinar:
>
> ftw.upgrade = 3.0.0
>
> no seu buildout. Ver:
>
> https://github.com/plonegovbr/brasil.gov.portal/issues/606
>
> Wesley
>
> Em seg., 8 de fev. de 2021 às 20:24, Joaby Augusto <
> joabyaugu...@hotmail.com> escreveu:
>
> Olá boa noite,
>
> Estou tentando instalar o IDG 2.1.1 e me ocorre esse erro:
>
> Version and requirements information containing six:
>
>   [versions] constraint on six: 1.10.0
>
>   Requirement of brasil.gov.portal==2.1.1: six
>
>   Requirement of z3c.form: six
>
>   Requirement of plone.contentrules: six
>
>   Requirement of plone.api: six
>
>   Requirement of collective.fingerpointing: six
>
>   Requirement of collective.cover: six
>
>   Requirement of brasil.gov.tiles: six
>
>   Requirement of brasil.gov.agenda: six
>
>   Requirement of Products.CMFQuickInstallerTool: six
>
>   Requirement of plone.app.textfield: six
>
>   Requirement of plone.transformchain: six
>
>   Requirement of plone.folder: six
>
>   Requirement of Products.CMFDynamicViewFTI: six
>
>   Requirement of plone.subrequest: six
>
>   Requirement of diazo>=1.0.3: six
>
>   Requirement of z3c.pt>=2.2: six
>
>   Requirement of ftw.upgrade: six>=1.12.0
>
> While:
>
>   Installing instance.
>
> Error: The requirement ('six>=1.12.0') is not allowed by your [versions]
> constraint (1.10.0)
>
>
>
> Alguém ja se deparou com esse erro? como solucioná-lo?
>
> Abraço.
>
> --
> Comunidade Plone no Governo
> Site: http://www.softwarelivre.gov.br/plone
> Wiki: http://colab.interlegis.leg.br/wiki/PloneGovBr
> Histórico:
> http://colab.interlegis.leg.br/search/?type=thread=latest=plonegov-br
> Lista: https://listas.interlegis.gov.br/mailman/listinfo/plonegov-br
>
> --
> Comunidade Plone no Governo
> Site: http://www.softwarelivre.gov.br/plone
> Wiki: http://colab.interlegis.leg.br/wiki/PloneGovBr
> Histórico:
> http://colab.interlegis.leg.br/search/?type=thread=latest=plonegov-br
> Lista: https://listas.interlegis.gov.br/mailman/listinfo/plonegov-br
-- 
Comunidade Plone no Governo
Site: http://www.softwarelivre.gov.br/plone
Wiki: http://colab.interlegis.leg.br/wiki/PloneGovBr
Histórico: 
http://colab.interlegis.leg.br/search/?type=thread=latest=plonegov-br
Lista: https://listas.interlegis.gov.br/mailman/listinfo/plonegov-br

Re: [plonegov-br] Erro ao tentar instalar Portal

[Wesley Lopes]

Manda o traceback.

Em ter., 9 de fev. de 2021 às 01:13, Joaby Augusto 
escreveu:

> Olá Wesley,
>
> Fiz o procedimento que você mencionou, mais sem êxito.
>
> Infelizmente o erro persiste.
> --
> *De:* plonegov-br-boun...@listas.interlegis.gov.br <
> plonegov-br-boun...@listas.interlegis.gov.br> em nome de Wesley Lopes <
> wesle...@gmail.com>
> *Enviado:* segunda-feira, 8 de fevereiro de 2021 21:29
> *Para:* Comunidade Plone no Governo 
> *Assunto:* Re: [plonegov-br] Erro ao tentar instalar Portal
>
> Olá Joaby!
>
> Você pode tentar pinar:
>
> ftw.upgrade = 3.0.0
>
> no seu buildout. Ver:
>
> https://github.com/plonegovbr/brasil.gov.portal/issues/606
>
> Wesley
>
> Em seg., 8 de fev. de 2021 às 20:24, Joaby Augusto <
> joabyaugu...@hotmail.com> escreveu:
>
> Olá boa noite,
>
> Estou tentando instalar o IDG 2.1.1 e me ocorre esse erro:
>
> Version and requirements information containing six:
>
>   [versions] constraint on six: 1.10.0
>
>   Requirement of brasil.gov.portal==2.1.1: six
>
>   Requirement of z3c.form: six
>
>   Requirement of plone.contentrules: six
>
>   Requirement of plone.api: six
>
>   Requirement of collective.fingerpointing: six
>
>   Requirement of collective.cover: six
>
>   Requirement of brasil.gov.tiles: six
>
>   Requirement of brasil.gov.agenda: six
>
>   Requirement of Products.CMFQuickInstallerTool: six
>
>   Requirement of plone.app.textfield: six
>
>   Requirement of plone.transformchain: six
>
>   Requirement of plone.folder: six
>
>   Requirement of Products.CMFDynamicViewFTI: six
>
>   Requirement of plone.subrequest: six
>
>   Requirement of diazo>=1.0.3: six
>
>   Requirement of z3c.pt>=2.2: six
>
>   Requirement of ftw.upgrade: six>=1.12.0
>
> While:
>
>   Installing instance.
>
> Error: The requirement ('six>=1.12.0') is not allowed by your [versions]
> constraint (1.10.0)
>
>
>
> Alguém ja se deparou com esse erro? como solucioná-lo?
>
> Abraço.
>
> --
> Comunidade Plone no Governo
> Site: http://www.softwarelivre.gov.br/plone
> Wiki: http://colab.interlegis.leg.br/wiki/PloneGovBr
> Histórico:
> http://colab.interlegis.leg.br/search/?type=thread=latest=plonegov-br
> Lista: https://listas.interlegis.gov.br/mailman/listinfo/plonegov-br
>
> --
> Comunidade Plone no Governo
> Site: http://www.softwarelivre.gov.br/plone
> Wiki: http://colab.interlegis.leg.br/wiki/PloneGovBr
> Histórico:
> http://colab.interlegis.leg.br/search/?type=thread=latest=plonegov-br
> Lista: https://listas.interlegis.gov.br/mailman/listinfo/plonegov-br
-- 
Comunidade Plone no Governo
Site: http://www.softwarelivre.gov.br/plone
Wiki: http://colab.interlegis.leg.br/wiki/PloneGovBr
Histórico: 
http://colab.interlegis.leg.br/search/?type=thread=latest=plonegov-br
Lista: https://listas.interlegis.gov.br/mailman/listinfo/plonegov-br

Re: [plonegov-br] Erro ao tentar instalar Portal

[Wesley Lopes]

Olá Joaby!

Você pode tentar pinar:

ftw.upgrade = 3.0.0

no seu buildout. Ver:

https://github.com/plonegovbr/brasil.gov.portal/issues/606

Wesley

Em seg., 8 de fev. de 2021 às 20:24, Joaby Augusto 
escreveu:

> Olá boa noite,
>
> Estou tentando instalar o IDG 2.1.1 e me ocorre esse erro:
>
> Version and requirements information containing six:
>
>   [versions] constraint on six: 1.10.0
>
>   Requirement of brasil.gov.portal==2.1.1: six
>
>   Requirement of z3c.form: six
>
>   Requirement of plone.contentrules: six
>
>   Requirement of plone.api: six
>
>   Requirement of collective.fingerpointing: six
>
>   Requirement of collective.cover: six
>
>   Requirement of brasil.gov.tiles: six
>
>   Requirement of brasil.gov.agenda: six
>
>   Requirement of Products.CMFQuickInstallerTool: six
>
>   Requirement of plone.app.textfield: six
>
>   Requirement of plone.transformchain: six
>
>   Requirement of plone.folder: six
>
>   Requirement of Products.CMFDynamicViewFTI: six
>
>   Requirement of plone.subrequest: six
>
>   Requirement of diazo>=1.0.3: six
>
>   Requirement of z3c.pt>=2.2: six
>
>   Requirement of ftw.upgrade: six>=1.12.0
>
> While:
>
>   Installing instance.
>
> Error: The requirement ('six>=1.12.0') is not allowed by your [versions]
> constraint (1.10.0)
>
>
>
> Alguém ja se deparou com esse erro? como solucioná-lo?
>
> Abraço.
>
> --
> Comunidade Plone no Governo
> Site: http://www.softwarelivre.gov.br/plone
> Wiki: http://colab.interlegis.leg.br/wiki/PloneGovBr
> Histórico:
> http://colab.interlegis.leg.br/search/?type=thread=latest=plonegov-br
> Lista: https://listas.interlegis.gov.br/mailman/listinfo/plonegov-br
-- 
Comunidade Plone no Governo
Site: http://www.softwarelivre.gov.br/plone
Wiki: http://colab.interlegis.leg.br/wiki/PloneGovBr
Histórico: 
http://colab.interlegis.leg.br/search/?type=thread=latest=plonegov-br
Lista: https://listas.interlegis.gov.br/mailman/listinfo/plonegov-br

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

[Wesley Peng]

what's DBI sharing? do you mean Apache::DBI?
Does perl has Java similar DB connection pool?

Thanks.

On Mon, Feb 8, 2021, at 4:21 AM, James Smith wrote:
> DBI sharing doesn't really gain you much - and can actually lead you into a 
> whole world of pain. It isn't actually worth turning it on at all.
> 
> We use dedicated DB caching in the cases where we benefit from it as and when 
> you need it (low level caching database)...
> 
> Although milage may vary - our problem was DB servers with 30 or 40 databases 
> on them being connected from a number of approximately 50-100 child apaches, 
> meant we ended up blowing up the connections to the database server really 
> quickly...
> 
> 
> -Original Message-
> From: Vincent Veyron  
> Sent: 07 February 2021 19:06
> To: Steven Haigh 
> Cc: James Smith ; modperl@perl.apache.org
> Subject: Re: Moving ExecCGI to mod_perl - performance and custom 'modules' 
> [EXT]
> 
> On Sun, 07 Feb 2021 23:58:17 +1100
> Steven Haigh  wrote:
> > 
> > I haven't gotten into the preload or DBI sharing yet - as that'll end 
> > up needing a bit of a rewrite of code to take advantage of. I'd be 
> > open to suggestions here from those who have done it in the past to 
> > save me going down some dead ends :D
> 
> I use mod_perl handlers, so not sure how it mixes with PerlRegistry, but you 
> probably want to have a look at connect_cached
> 
> 
> -- 
> 
> Bien à vous, Vincent Veyron 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__compta.libremen.com=DwIFAw=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=oH2yp0ge1ecj4oDX0XM7vQ=C0OcuGbNbfxaSa8ASgV3uFXzejn7MpjIUH1aP1RbiyU=GPr8VuKQ3rZCzCPwggyAHdCOojK6ZThmShKk0Jb3maI=
> Logiciel libre de comptabilité générale en partie double
> 
> 
> 
> --
> The Wellcome Sanger Institute is operated by Genome Research
> Limited, a charity registered in England with number 1021457 and a
> company registered in England with number 2742969, whose registered
> office is 215 Euston Road, London, NW1 2BE.
> 

Re: Moving ExecCGI to mod_perl - performance and custom'modules'[EXT]

[Wesley Peng]

If you can take time to rewrite all codes with modPerl handlers, that will 
improve performance a lot.

On Sun, Feb 7, 2021, at 9:14 PM, Steven Haigh wrote:
> In fact, I just realised that 'ab' test is rather restrictive So here's a 
> bit more of an extended test:
> 
> # ab -k -n 1000 -c 32
> 
> Apache + ExecCGI:
> Requests per second:14.26 [#/sec] (mean)
> Time per request:   2244.181 [ms] (mean)
> Time per request:   70.131 [ms] (mean, across all concurrent requests)
> 
> Apache + mod_perl (ModPerl::PerlRegistry): 
> Requests per second: 132.14 [#/sec] (mean)
> Time per request:   242.175 [ms] (mean)
> Time per request:   7.568 [ms] (mean, across all concurrent requests)
> 
> Interestingly, without Keepalives, the story is much the same:
> 
> # ab -n 1000 -c 32
> 
> Apache + ExecCGI:
> Requests per second:14.15 [#/sec] (mean)
> Time per request:   2260.875 [ms] (mean)
> Time per request:   70.652 [ms] (mean, across all concurrent requests)
> 
> Apache + mod_perl (ModPerl::PerlRegistry): 
> Requests per second:154.48 [#/sec] (mean)
> Time per request:   207.140 [ms] (mean)
> Time per request:   6.473 [ms] (mean, across all concurrent requests)
> 
> Running some benchmarks across various parts of my site made me realise I 
> also had some RewriteRules in the apache config that still had H=cgi-script - 
> changed those to H=perl-script and saw similar improvements:
> 
> ExecCGI - Requests per second:11.84 [#/sec] (mean)
> mod_perl - Requests per second:130.97 [#/sec] (mean)
> 
> That's quite some gains for a days work.
> 
> --
> Steven Haigh  net...@crc.id.au  https://www.crc.id.au
> 
> On Sun, Feb 7, 2021 at 23:58, Steven Haigh  wrote:
>> Interestingly, I did get things working with ModPerl::PerlRegistry.
>> 
>> What I couldn't find *anywhere* is that the data I was loading in Template 
>> Toolkit was included in the file in the __DATA__ area - which causes 
>> mod_perl to fall over!
>> 
>> The only way I managed to find this was the following error in the *system* 
>> /var/log/httpd/error_log (didn't show up in the vhost error_log!):
>> readline() on unopened filehandle DATA at 
>> /usr/lib64/perl5/vendor_perl/Template/Provider.pm line 638.
>> 
>> Took me a LONG time to find a vague post that reading in lines from  
>> kills mod_perl. Not sure why - but I stripped all the templates out and put 
>> them in a file instead and re-wrote that bit of code, and things started 
>> working.
>> 
>> I had to fix a few lib path issues, but after getting my head around that, 
>> most things seem to work as before - however I don't notice much of an 
>> improvement in execution times, I do see this improvement using 'ab -n 100 
>> -c32':
>> 
>> Apache + ExecCGI: Requests per second:13.50 [#/sec] (mean)
>> Apache + mod_perl: Requests per second:59.81 [#/sec] (mean)
>> 
>> This is obviously a good thing.
>> 
>> I haven't gotten into the preload or DBI sharing yet - as that'll end up 
>> needing a bit of a rewrite of code to take advantage of. I'd be open to 
>> suggestions here from those who have done it in the past to save me going 
>> down some dead ends :D
>> 
>> --
>> Steven Haigh  net...@crc.id.au  https://www.crc.id.au
>> 
>> On Sun, Feb 7, 2021 at 12:49, James Smith  wrote:
>>> As welsey said – try Registry, that was the standard way of using mod_perl 
>>> to cache perl in the server  – but your problem might be due to the note in 
>>> PerlRun…
>>> 
>>> https://perl.apache.org/docs/2.0/api/ModPerl/PerlRun.html#Description
>>> META: document that for now we don't chdir() into the script's dir, because 
>>> it affects the whole process under threads. `ModPerl::PerlRunPrefork 
>>> ` should 
>>> be used by those who run only under prefork MPM.
>>> {tbh most people don’t use mod perl under threads anyway as there isn’t 
>>> really a gain from using them}
>>> 
>>> It suggests you use ModPerl/PerlRunPrefork – as this does an additional 
>>> step to cd to the script directory – which might be your issue….

>>>  

>>> *From:* Steven Haigh  
>>> *Sent:* 07 February 2021 01:00
>>> *To:* modperl@perl.apache.org
>>> *Subject:* Moving ExecCGI to mod_perl - performance and custom 'modules' 
>>> [EXT]

>>>  

>>> Hi all,

>>>  

>>> So for many years I've been slack and writing perl scripts to do various 
>>> things - but never needed more than the normal apache +ExecCGI and Template 
>>> Toolkit.

>>>  

>>> One of my sites has become a bit more popular, so I'd like to spend a bit 
>>> of time on performance. Currently, I'm seeing ~300-400ms of what I believe 
>>> to be execution time of the script loading, running, and then blatting its 
>>> output to STDOUT and the browser can go do its thing. 

>>>  

>>> I believe most of the delay would be to do with loading perl, its modules 
>>> etc etc

>>>  

>>> I know that the current trend would be to re-write the entire site in a 
>>> more modern, 

Re: Moving ExecCGI to mod_perl - performance and custom 'modules'

[Wesley Peng]

Is the url in your signature the website? It looks a beautiful UI design.
And you can try this method:
https://metacpan.org/pod/ModPerl::Registry

Thanks.

On Sun, Feb 7, 2021, at 8:59 AM, Steven Haigh wrote:
> Hi all,
> 
> So for many years I've been slack and writing perl scripts to do various 
> things - but never needed more than the normal apache +ExecCGI and Template 
> Toolkit.
> 
> One of my sites has become a bit more popular, so I'd like to spend a bit of 
> time on performance. Currently, I'm seeing ~300-400ms of what I believe to be 
> execution time of the script loading, running, and then blatting its output 
> to STDOUT and the browser can go do its thing. 
> 
> I believe most of the delay would be to do with loading perl, its modules etc 
> etc
> 
> I know that the current trend would be to re-write the entire site in a more 
> modern, daemon based solution - and I started down the Mojolicious path - but 
> the amount of re-writing to save 1/3rd of a second seems to be excessive
> 
> Would I be correct in thinking that mod_perl would help in this case?
> 
> I did try a basic test, but I have a 'use functions' in all my scripts that 
> loads a .pm with some global vars and a lot of common subs - and for whatever 
> reason (can't find anything on Google as to why), none of the subs are 
> recognised in the main script when loaded via ModPerl::PerlRun.
> 
> So throwing it out to the list - am I on the right track? wasting my time? or 
> just a simple mistake?
> 
> --
> Steven Haigh  net...@crc.id.au  https://www.crc.id.au

Re: dimensions in a multidimensional array

[Wesley Peng]

When will we have p6’s Numpy?


On Sat, Feb 6, 2021, at 2:04 AM, Brad Gilbert wrote:
> There is a reason that you can't just ask for the dimensions of an 
> unspecified multidimensional array.
> It may be multiple dimensions.
> 
> [[1,2,3],
> [4,5,6,7,8,9,10]].shape
> 
> If it gave a result it would be something like:
> 
> (2,3|7)
> 
> On Fri, Feb 5, 2021 at 8:50 AM Theo van den Heuvel  
> wrote:
>> Hi gurus,
>> 
>> I cannot seem to find an idiomatic way to get the dimensions of a 
>> multidimensional array,
>> other than by looking at the size of the first row and column, with 
>> @m[0;*].elems and @m[*;0].elems.
>> Am I missing something in the docs?
>> 
>> Thanks,
>> 
>> -- 
>> Theo van den Heuvel
>> 

Re: dimensions in a multidimensional array

[Wesley Peng]

When will we have p6’s Numpy?


On Sat, Feb 6, 2021, at 2:04 AM, Brad Gilbert wrote:
> There is a reason that you can't just ask for the dimensions of an 
> unspecified multidimensional array.
> It may be multiple dimensions.
> 
> [[1,2,3],
> [4,5,6,7,8,9,10]].shape
> 
> If it gave a result it would be something like:
> 
> (2,3|7)
> 
> On Fri, Feb 5, 2021 at 8:50 AM Theo van den Heuvel  
> wrote:
>> Hi gurus,
>> 
>> I cannot seem to find an idiomatic way to get the dimensions of a 
>> multidimensional array,
>> other than by looking at the size of the first row and column, with 
>> @m[0;*].elems and @m[*;0].elems.
>> Am I missing something in the docs?
>> 
>> Thanks,
>> 
>> -- 
>> Theo van den Heuvel
>> 

Re: Please can you opt me out from receiving mails from you.

[Wesley Peng]

You can send an email to beginners-unsubscr...@perl.org to unsubscribe yourself 
from it.


On Fri, Feb 5, 2021, at 4:20 PM, ONYEDIKACHI NNADI wrote:
> Please can you opt my email address dikachi4...@gmail.com from receiving 
> emails from you. Thanks in anticipation for your prompt action. 

any blocked websocket client for perl?

[Wesley Peng]

I am trying to find a websocket client for perl.
But most modules on cpan is asynchronous, such as AnyEvent::WebSocket::Client.
Do you know if there is a synchronous websocket client library available?

Thanks in advance.


BTW, I tried to use the anyevent module above to access my WS service, it 
doesn't work.
When program run, it just hangs without any output.
Can you see why this happens?
The code as below:

use strict;

use JSON;

use Data::Dumper;

use AnyEvent::WebSocket::Client 0.12;

 

my $client = AnyEvent::WebSocket::Client->new;

my $url = 
'ws://localhost:8080/ws/v2/producer/persistent/public/default/my-topic';



 

$client->connect($url)->cb(sub {

 

  # make $connection an our variable rather than

  # my so that it will stick around.  Once the

  # connection falls out of scope any callbacks

  # tied to it will be destroyed.

  our $connection = eval { shift->recv };

  if($@) {

# handle error...

warn $@;

return;

  }

   

  # send a message through the websocket...

  my $payload = encode_json({'payload' => 'hello world'});

  $connection->send($payload);

   

  # recieve message from the websocket...

  $connection->on(each_message => sub {

# $connection is the same connection object

# $message isa AnyEvent::WebSocket::Message

my($connection, $message) = @_;

print Dumper decode_json($message);

  });

   

  # handle a closed connection...

#  $connection->on(finish => sub {

## $connection is the same connection object

#my($connection) = @_;

#...

#  });

 

  # close the connection (either inside or

  # outside another callback)

#  $connection->close;

 

});

 

## uncomment to enter the event loop before exiting.

## Note that calling recv on a condition variable before

## it has been triggered does not work on all event loops

AnyEvent->condvar->recv;

Re: [TV orNotTV] "Kate and Allie" reboot pilot to NBC

[Wesley (in Colorado)]

Funny thing, I kinda felt DC's "Harley Quinn" was a reboot of Kate and
Allie, but in brighter colors.

On Fri, Jan 29, 2021 at 8:10 PM 'Bob Jersey' via TVorNotTV <
tvornottv@googlegroups.com> wrote:

> Developed by Erica Oyama, cohort of Nahnatchka Khan at "Fresh Off The
> Boat" and "Young Rock"...
>
> https://variety.com/2021/tv/news/kate-and-allie-reboot-nbc-1234896072/
>  (link)
>
> B
>
> --
> You received this message because you are subscribed to the Google Groups
> "TVorNotTV" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tvornottv+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tvornottv/243ce57d-fa10-4a60-907f-5d5e71adee42n%40googlegroups.com
> <https://groups.google.com/d/msgid/tvornottv/243ce57d-fa10-4a60-907f-5d5e71adee42n%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Wesley McGee
http://www.ambivi.com
http://sterlingnorth.typepad.com
http://drawing-a-blank.tumblr.com

Twitter: @westwit
G+: http://plus.google.com/113413697748381364954
Facebook: http://www.facebook.com/wesleymcgee

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

[Mpi-forum] MPI 4.0 RC 2 Published

[Wesley Bland via mpi-forum]

Hi all,

The second release candidate for MPI 4.0 is now posted on our GitHub page.
This version will not be posted on the website directly because it no
longer includes the "Draft" tag, even though it is still a draft, in order
to have a review copy that is as close to the final version as possible.

https://github.com/mpi-forum/mpi-forum.github.io/raw/master/docs/mpi-4.0/mpi40-rc-feb-21.pdf

Please take a look at the document between now and the meeting in a few
weeks. Chapter chairs and their committees in particular should review
their chapters to ensure that all of the changes made between the previous
RC and this one are all still correct. We also want to look for any other
last minute issues with formatting, etc.

As Bill said during our virtual meeting today, there will always be
something that we immediately notice as a problem, but we should really be
looking for breaking issues that would prevent us from publishing 4.0.
Otherwise, we should note issues to be fixed for 4.1 (and remember that we
already have many of these noted so check to see if there's already an
issue for it).

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

[ovirt-users] Single Node 4.3 to 4.4 help

[Wesley Stewart]

I have read through many posts and I think this process seems fairly simple.

https://www.ovirt.org/documentation/upgrade_guide/#SHE_Upgrading_from_4-3

But I just wanted to see if anyone had any gotchas.  I am thinking of
either using

   - RHEL8 (Using developer program, probably best best atm)
   - Ovirt Node (Is ovirt node being deprecated since it is based on
   centos?)
   - Rocky Linux/AlmaLinux/Clear Linux

>From my understanding I should:

   - Enter global maintenance
   - Make a full engine backup
   - Reinstall to a supported OS
   - Deploy ovirt engine using backup.

Looking forward to trying out Ovirt 4.4!
___
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/FFDZPAJRBQ5B336JGPBPX2S2HASOT5PI/

Re: [VOTE] Relase Apache APISIX 2.3

[Wesley Peng]

Does it have an apt repo for installation on ubuntu? thanks.

On Wed, Feb 3, 2021, at 3:00 PM, dabue wrote:
> +1 binding
>  
> I checked:
>  
> 1. Download links are valid;
> 2. Checksums and PGP signatures are valid;
> 3. License and NOTICE files are good;
> 4. All files have the necessary License header;
> 5. Build successfully on Ubuntu 16  with Openresty 1.19
> 
> update the result of  run steps
> 
> ***
> 6. 1st Run
>It reports "apisix/core/utils.lua:22: module 'resty.dns.client' not found:"
> 
> 7. check the deps, find it added apisix of master-0 to the deps  when execute 
> 'make deps'
> check the luarocks version, find the version is too older,
> update the latest version  and redo 'make deps',
> get the correct deps.
> 8. 2nd Run,   sudo make run,   it works well.
> *** 
> 
> 
> 
> 
> 
>  
> From: dabue
> Date: 2021-02-03 11:37
> To: dev
> Subject: Re: [VOTE] Relase Apache APISIX 2.3
> +1 binding
>  
> I checked:
>  
> 1. Download links are valid;
> 2. Checksums and PGP signatures are valid;
> 3. License and NOTICE files are good;
> 4. All files have the necessary License header;
> 5. Build successfully on Ubuntu 16  with Openresty 1.19
> 
> ***
> 6. 1st Run
>It reports "apisix/core/utils.lua:22: module 'resty.dns.client' not found:"
> 
> 7. append  "lua-resty-dns-client = 5.2.1-1"  to 
> rockspec/apisix-master-0.rockspec
> 
> 8. redo make deps
> 
> 9. 2nd Run,   sudo make run,   it works well.
> *** 
> 
> 
> 
> 
>  
> From: Zexuan Luo
> Date: 2021-02-01 16:50
> To: dev
> Subject: [VOTE] Relase Apache APISIX 2.3
> Hello, Community,
> This is a call for the vote to release Apache APISIX version 2.3.
>  
> Release notes:
>  
> https://github.com/apache/apisix/blob/v2.3/CHANGELOG.md#230
>  
> The release candidates:
>  
> https://dist.apache.org/repos/dist/dev/apisix/2.3/
>  
> Release Commit ID:
>  
> https://github.com/apache/apisix/commit/529433bb94d3a6a8ae67f735c25d4cafacc887a5
>  
> Keys to verify the Release Candidate:
>  
> https://dist.apache.org/repos/dist/release/apisix/KEYS
>  
> Steps to validating the release:
>  
> 1. Download the release
>  
> wget
> https://dist.apache.org/repos/dist/dev/apisix/2.3/apache-apisix-2.3-src.tgz
>  
> 2. Checksums and signatures
>  
> wget https://dist.apache.org/repos/dist/release/apisix/KEYS
>  
> wget
> https://dist.apache.org/repos/dist/dev/apisix/2.3/apache-apisix-2.3-src.tgz.asc
>  
> wget
> https://dist.apache.org/repos/dist/dev/apisix/2.3/apache-apisix-2.3-src.tgz.sha512
>  
> shasum -c apache-apisix-2.3-src.tgz.sha512
>  
> gpg --verify apache-apisix-2.3-src.tgz.asc apache-apisix-2.3-src.tgz
>  
> 3. Unzip and Check files
>  
> tar zxvf apache-apisix-2.3-src.tgz
>  
> 4. Build Apache APISIX:
>  
> https://github.com/apache/apisix/blob/master/doc/how-to-build.md#installation-via-source-
> release
>  
> The vote will be open for at least 72 hours or until necessary number of
> votes are reached.
>  
> Please vote accordingly:
>  
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
> 

[Mpi-forum] Last Call for MPI 4.0 Officer Nominations and February Meeting Topics

[Wesley Bland via mpi-forum]

Hi all,

I just wanted to remind everyone that Monday is the deadline for officer 
nominations for MPI 4.0 since the February meeting is a Final Ratification 
Meeting.

If you would like to nominate someone (or yourself) for any of the officer 
positions, please send an announcement to the mailing list before the end of 
the day on Monday.

You can find the current nominees on the agenda page for that meeting here: 
https://www.mpi-forum.org/meetings/2021/02/agenda 


Monday is also the deadline for any readings or votes that need to be announced 
before the same meeting so please do those as well.

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

[aur-requests] Fwd: qt5-styleplugins for community repo

[Wayne Wesley via aur-requests]

hey i would like to know if there is any chance to have qt5-styleplugins
moved to the community  repo as seems to have the votes needed and many
users benefit from the package :)

Thanks

Wayne Wesley (TheRepoClub)

A simple publish takes 9s to finish

[Wesley Peng]

Can you please see below why a simple publish take 9s to finish?
Pulsar is deployed on a two cores VPS, and I run it with `pulsar-daemon start 
standalone` mode.

Thanks.

$ time bin/pulsar-client produce my-topic --messages "hello-pullsar fifth"

15:06:12.815 [pulsar-client-io-1-1] INFO  
org.apache.pulsar.client.impl.ConnectionPool - [[id: 0x90192576, 
L:/127.0.0.1:45148 - R:localhost/127.0.0.1:6650]] Connected to server

15:06:13.385 [pulsar-client-io-1-1] INFO  
org.apache.pulsar.client.impl.ProducerStatsRecorderImpl - Starting Pulsar 
producer perf with config: {

  "topicName" : "my-topic",

  "producerName" : null,

  "sendTimeoutMs" : 3,

  "blockIfQueueFull" : false,

  "maxPendingMessages" : 1000,

  "maxPendingMessagesAcrossPartitions" : 5,

  "messageRoutingMode" : "RoundRobinPartition",

  "hashingScheme" : "JavaStringHash",

  "cryptoFailureAction" : "FAIL",

  "batchingMaxPublishDelayMicros" : 1000,

  "batchingPartitionSwitchFrequencyByPublishDelay" : 10,

  "batchingMaxMessages" : 1000,

  "batchingMaxBytes" : 131072,

  "batchingEnabled" : true,

  "chunkingEnabled" : false,

  "compressionType" : "NONE",

  "initialSequenceId" : null,

  "autoUpdatePartitions" : true,

  "autoUpdatePartitionsIntervalSeconds" : 60,

  "multiSchema" : true,

  "properties" : { }

}

15:06:13.411 [pulsar-client-io-1-1] INFO  
org.apache.pulsar.client.impl.ProducerStatsRecorderImpl - Pulsar client config: 
{

  "serviceUrl" : "pulsar://localhost:6650/",

  "authPluginClassName" : null,

  "operationTimeoutMs" : 3,

  "statsIntervalSeconds" : 60,

  "numIoThreads" : 1,

  "numListenerThreads" : 1,

  "connectionsPerBroker" : 1,

  "useTcpNoDelay" : true,

  "useTls" : false,

  "tlsTrustCertsFilePath" : "",

  "tlsAllowInsecureConnection" : false,

  "tlsHostnameVerificationEnable" : false,

  "concurrentLookupRequest" : 5000,

  "maxLookupRequest" : 5,

  "maxLookupRedirects" : 20,

  "maxNumberOfRejectedRequestPerConnection" : 50,

  "keepAliveIntervalSeconds" : 30,

  "connectionTimeoutMs" : 1,

  "requestTimeoutMs" : 6,

  "initialBackoffIntervalNanos" : 1,

  "maxBackoffIntervalNanos" : 600,

  "listenerName" : null,

  "useKeyStoreTls" : false,

  "sslProvider" : null,

  "tlsTrustStoreType" : "JKS",

  "tlsTrustStorePath" : "",

  "tlsTrustStorePassword" : "",

  "tlsCiphers" : [ ],

  "tlsProtocols" : [ ],

  "proxyServiceUrl" : null,

  "proxyProtocol" : null,

  "enableTransaction" : false

}

15:06:13.485 [pulsar-client-io-1-1] INFO  
org.apache.pulsar.client.impl.ProducerImpl - [my-topic] [null] Creating 
producer on cnx [id: 0x90192576, L:/127.0.0.1:45148 - 
R:localhost/127.0.0.1:6650]

15:06:13.576 [pulsar-client-io-1-1] INFO  
org.apache.pulsar.client.impl.ProducerImpl - [my-topic] [standalone-1-4] 
Created producer on cnx [id: 0x90192576, L:/127.0.0.1:45148 - 
R:localhost/127.0.0.1:6650]

15:06:13.919 [pulsar-client-io-1-1] INFO  
com.scurrilous.circe.checksum.Crc32cIntChecksum - SSE4.2 CRC32C provider 
initialized

15:06:14.002 [main] INFO  org.apache.pulsar.client.impl.PulsarClientImpl - 
Client closing. URL: pulsar://localhost:6650/

15:06:14.054 [main] INFO  org.apache.pulsar.client.impl.ProducerImpl - 
[my-topic] [standalone-1-4] Closed Producer

15:06:14.090 [pulsar-client-io-1-1] INFO  
org.apache.pulsar.client.impl.ClientCnx - [id: 0x90192576, L:/127.0.0.1:45148 ! 
R:localhost/127.0.0.1:6650] Disconnected

15:06:14.164 [main] INFO  org.apache.pulsar.client.cli.PulsarClientTool - 1 
messages successfully produced



real 0m9.011s

user 0m10.884s

sys 0m1.172s

Re: CPU consuming question

[Wesley Peng]

Can you help check with log output?

$ tail -f pulsar-standalone-PresentSpicy-VM.log 

14:45:14.281 [main-EventThread] INFO  
org.apache.distributedlog.logsegment.PerStreamLogSegmentCache - 
01/01/00/checkpoints/0352d14e-8a42-4453-89ed-1fbf34051b76/CURRENT
 added log segment (logrecs_01 : [LogSegmentId:279, 
firstTxId:16, lastTxId:16, version:VERSION_V5_SEQUENCE_ID, 
completionTime:1612161014650, recordCount:1, regionId:0, status:0, 
logSegmentSequenceNumber:1, lastEntryId:0, lastSlotId:0, inprogress:false, 
minActiveDLSN:DLSN{logSegmentSequenceNo=1, entryId=0, slotId=0}, 
startSequenceId:0]) to cache.

14:45:14.297 [DLM-/stream/storage-OrderedScheduler-1-0] INFO  
org.apache.distributedlog.BKLogWriteHandler - Deleting ledger 
[LogSegmentId:279, firstTxId:16, lastTxId:16, version:VERSION_V5_SEQUENCE_ID, 
completionTime:1612161014650, recordCount:1, regionId:0, status:0, 
logSegmentSequenceNumber:1, lastEntryId:0, lastSlotId:0, inprogress:false, 
minActiveDLSN:DLSN{logSegmentSequenceNo=1, entryId=0, slotId=0}, 
startSequenceId:0] for 
01/01/00/checkpoints/0352d14e-8a42-4453-89ed-1fbf34051b76/CURRENT:

14:45:14.301 [BookKeeperClientWorker-OrderedExecutor-0-0] INFO  
org.apache.distributedlog.impl.ZKLogSegmentMetadataStore - Delete segment : 
[LogSegmentId:279, firstTxId:16, lastTxId:16, version:VERSION_V5_SEQUENCE_ID, 
completionTime:1612161014650, recordCount:1, regionId:0, status:0, 
logSegmentSequenceNumber:1, lastEntryId:0, lastSlotId:0, inprogress:false, 
minActiveDLSN:DLSN{logSegmentSequenceNo=1, entryId=0, slotId=0}, 
startSequenceId:0]

14:45:14.331 [main-EventThread] INFO  
org.apache.distributedlog.bk.SimpleLedgerAllocator - Ledger allocator for 
/stream/storage/01/01/00/checkpoints/0352d14e-8a42-4453-89ed-1fbf34051b76//allocation
 moved version from -1 to 0.

14:45:14.349 [io-checkpoint-scheduler-OrderedScheduler-1-0] INFO  
org.apache.bookkeeper.statelib.impl.rocksdb.checkpoint.RocksdbCheckpointTask - 
Delete remote checkpoint 0352d14e-8a42-4453-89ed-1fbf34051b76 from checkpoint 
store at 
01/01/00/checkpoints/0352d14e-8a42-4453-89ed-1fbf34051b76

14:45:33.435 [pulsar-web-68-5] INFO  org.eclipse.jetty.server.RequestLog - 
127.0.0.1 - - [01/Feb/2021:14:45:33 +0800] "GET 
/admin/v2/persistent/public/functions/coordinate/stats?getPreciseBacklog=false 
HTTP/1.1" 200 1401 "-" "Pulsar-Java-v2.7.0" 10

14:46:03.429 [pulsar-web-68-1] INFO  org.eclipse.jetty.server.RequestLog - 
127.0.0.1 - - [01/Feb/2021:14:46:03 +0800] "GET 
/admin/v2/persistent/public/functions/coordinate/stats?getPreciseBacklog=false 
HTTP/1.1" 200 1401 "-" "Pulsar-Java-v2.7.0" 6

14:46:33.441 [pulsar-web-68-6] INFO  org.eclipse.jetty.server.RequestLog - 
127.0.0.1 - - [01/Feb/2021:14:46:33 +0800] "GET 
/admin/v2/persistent/public/functions/coordinate/stats?getPreciseBacklog=false 
HTTP/1.1" 200 1401 "-" "Pulsar-Java-v2.7.0" 10

14:47:03.431 [pulsar-web-68-8] INFO  org.eclipse.jetty.server.RequestLog - 
127.0.0.1 - - [01/Feb/2021:14:47:03 +0800] "GET 
/admin/v2/persistent/public/functions/coordinate/stats?getPreciseBacklog=false 
HTTP/1.1" 200 1401 "-" "Pulsar-Java-v2.7.0" 7



Thank you
Regards.


On Mon, Feb 1, 2021, at 2:30 PM, Sijie Guo wrote:
> Hi Wesley,
> 
> The CPU usage might be coming from some background tasks. Do you happen to 
> have the log of the standalone server? This might give some insights to the 
> problem. 
> 
> - Sijie
> 
> On Sun, Jan 31, 2021 at 9:58 PM Wesley Peng  wrote:
>> __
>> I deployed a standalone pulsar server on a two cores VPS, which was new 
>> installed.
>> Even there is not any jobs running on pulsar, it still consumes CPU about 
>> 15+%.
>> 'top' shows the java process takes it.
>> 
>> Can you help explain this? Thank you.
>> 
>> Regards.

CPU consuming question

[Wesley Peng]

I deployed a standalone pulsar server on a two cores VPS, which was new 
installed.
Even there is not any jobs running on pulsar, it still consumes CPU about 15+%.
'top' shows the java process takes it.

Can you help explain this? Thank you.

Regards.

Re: perl.com's registration appears to have been hijacked

[Wesley Peng]

Nice sender domain. You would better sell it to ruby language developer.

On Sun, Jan 31, 2021, at 5:20 AM, Earl Ruby wrote:
> Re-sending using the "from" address that's subscribed to the list... 
> 
> On Fri, Jan 29, 2021 at 3:07 PM Earl Ruby  wrote:
>> A glance at the domain records show the contact information is now "REDACTED 
>> FOR PRIVACY". Prior to the change Tom Christiansen was listed as the domain 
>> administrative contact.
>> 
>> https://www.theregister.com/2021/01/28/perl_hijacking/
>> 
>> https://nakedsecurity.sophos.com/2021/01/29/the-mystery-of-the-missing-perl-webite/
>> 
> 
> -- 
> Earl Ruby
> http://earlruby.org/
> http://www.linkedin.com/in/earlruby
> https://twitter.com/earlruby

Re: perl.com's registration appears to have been hijacked

[Wesley Peng]

Nice sender domain. You would better sell it to ruby language developer.

On Sun, Jan 31, 2021, at 5:20 AM, Earl Ruby wrote:
> Re-sending using the "from" address that's subscribed to the list... 
> 
> On Fri, Jan 29, 2021 at 3:07 PM Earl Ruby  wrote:
>> A glance at the domain records show the contact information is now "REDACTED 
>> FOR PRIVACY". Prior to the change Tom Christiansen was listed as the domain 
>> administrative contact.
>> 
>> https://www.theregister.com/2021/01/28/perl_hijacking/
>> 
>> https://nakedsecurity.sophos.com/2021/01/29/the-mystery-of-the-missing-perl-webite/
>> 
> 
> -- 
> Earl Ruby
> http://earlruby.org/
> http://www.linkedin.com/in/earlruby
> https://twitter.com/earlruby

pulsar with perl from rest API

[Wesley Peng]

Hello

I need to write some codes with perl for accessing to pulsar cluster.
Can we use the rest API for this purpose since there is not the native client 
library for perl yet?

Thanks.

Re: [PATCH v7 4/5] usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default

[Wesley Cheng]

On 1/29/2021 1:24 AM, Jack Pham wrote:
> Hi Wesley,
> 
> On Thu, Jan 28, 2021 at 08:46:43PM -0800, Wesley Cheng wrote:
>> In order to take advantage of the TX fifo resizing logic, manually add
>> these properties to the DWC3 child node by default.  This will allow
>> the DWC3 gadget to resize the TX fifos for the IN endpoints, which
>> help with performance.
>>
>> Signed-off-by: Wesley Cheng 
>> ---
>>  drivers/usb/dwc3/dwc3-qcom.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
>> index d803ee9..4ea6be3 100644
>> --- a/drivers/usb/dwc3/dwc3-qcom.c
>> +++ b/drivers/usb/dwc3/dwc3-qcom.c
>> @@ -564,6 +564,7 @@ static int dwc3_qcom_clk_init(struct dwc3_qcom *qcom, 
>> int count)
>>  
>>  static const struct property_entry dwc3_qcom_acpi_properties[] = {
>>  PROPERTY_ENTRY_STRING("dr_mode", "host"),
>> +PROPERTY_ENTRY_BOOL("tx-fifo-resize"),
>>  {}
>>  };
>>  
>> @@ -634,6 +635,7 @@ static int dwc3_qcom_of_register_core(struct 
>> platform_device *pdev)
>>  struct dwc3_qcom*qcom = platform_get_drvdata(pdev);
>>  struct device_node  *np = pdev->dev.of_node, *dwc3_np;
>>  struct device   *dev = >dev;
>> +struct property *prop;
>>  int ret;
>>  
>>  dwc3_np = of_get_child_by_name(np, "dwc3");
>> @@ -642,6 +644,14 @@ static int dwc3_qcom_of_register_core(struct 
>> platform_device *pdev)
>>  return -ENODEV;
>>  }
>>  
>> +prop = kzalloc(sizeof(*prop), GFP_KERNEL);
>> +if (prop) {
>> +prop->name = "tx-fifo-resize";
>> +ret = of_add_property(dwc3_np, prop);
>> +if (ret < 0)
>> +dev_info(dev, "unable to add tx-fifo-resize prop\n");
> 
> You'll need to kfree(prop) both in case of error here as well as in the
> driver's .remove() callback. Maybe easier to devm_kzalloc()?

Hi Jack,

Thanks for the catch, will fix this with the devm variant.

Hi Bjorn,

Just wanted to see what you thought about this approach?  This way we
can just keep the dt binding w/o having to re-add it in the future, as
well as not needing to enable this property on every qcom platform with
dwc3.

Tested on my set up, and removed the change which added the property
from the DTSI node.

Thanks
Wesley Cheng

> 
> Jack
> 

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

[PATCH v7 5/5] dt-bindings: usb: dwc3: Update dwc3 TX fifo properties

[Wesley Cheng]

Update the tx-fifo-resize property with a better description, while
adding the tx-fifo-max-num, which is a new parameter allowing
adjustments for the maximum number of packets the txfifo resizing logic
can account for while resizing the endpoints.

Signed-off-by: Wesley Cheng 
---
 Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml 
b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index 2247da7..652b246 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -283,10 +283,21 @@ properties:
 maximum: 16
 
   tx-fifo-resize:
-description: Determines if the FIFO *has* to be reallocated
-deprecated: true
+description: Determines if the TX fifos can be dynamically resized 
depending
+  on the number of IN endpoints used and if bursting is supported.  This
+  may help improve bandwidth on platforms with higher system latencies, as
+  increased fifo space allows for the controller to prefetch data into its
+  internal memory.
 type: boolean
 
+  tx-fifo-max-num:
+description: Specifies the max number of packets the txfifo resizing logic
+  can account for when higher endpoint bursting is used. (bMaxBurst > 6) 
The
+  higher the number, the more fifo space the txfifo resizing logic will
+  allocate for that endpoint.
+$ref: /schemas/types.yaml#/definitions/uint8
+minimum: 3
+
   snps,incr-burst-type-adjustment:
 description:
   Value for INCR burst type of GSBUSCFG0 register, undefined length INCR
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 2/5] usb: gadget: configfs: Check USB configuration before adding

[Wesley Cheng]

Ensure that the USB gadget is able to support the configuration being
added based on the number of endpoints required from all interfaces.  This
is for accounting for any bandwidth or space limitations.

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

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 0d56f33..e6de3ca5 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1368,6 +1368,7 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
struct usb_function *f;
struct usb_function *tmp;
struct gadget_config_name *cn;
+   unsigned long ep_map = 0;
 
if (gadget_is_otg(gadget))
c->descriptors = otg_desc;
@@ -1397,7 +1398,28 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
list_add(>list, >func_list);
goto err_purge_funcs;
}
+   if (f->fs_descriptors) {
+   struct usb_descriptor_header **d;
+
+   d = f->fs_descriptors;
+   for (; *d; ++d) {
+   struct usb_endpoint_descriptor *ep;
+   int addr;
+
+   if ((*d)->bDescriptorType != 
USB_DT_ENDPOINT)
+   continue;
+
+   ep = (struct usb_endpoint_descriptor 
*)*d;
+   addr = ((ep->bEndpointAddress & 0x80) 
>> 3) |
+   (ep->bEndpointAddress & 0x0f);
+   set_bit(addr, _map);
+   }
+   }
}
+   ret = usb_gadget_check_config(cdev->gadget, ep_map);
+   if (ret)
+   goto err_purge_funcs;
+
usb_ep_autoconfig_reset(cdev->gadget);
}
if (cdev->use_os_string) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 4/5] usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default

[Wesley Cheng]

In order to take advantage of the TX fifo resizing logic, manually add
these properties to the DWC3 child node by default.  This will allow
the DWC3 gadget to resize the TX fifos for the IN endpoints, which
help with performance.

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

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index d803ee9..4ea6be3 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -564,6 +564,7 @@ static int dwc3_qcom_clk_init(struct dwc3_qcom *qcom, int 
count)
 
 static const struct property_entry dwc3_qcom_acpi_properties[] = {
PROPERTY_ENTRY_STRING("dr_mode", "host"),
+   PROPERTY_ENTRY_BOOL("tx-fifo-resize"),
{}
 };
 
@@ -634,6 +635,7 @@ static int dwc3_qcom_of_register_core(struct 
platform_device *pdev)
struct dwc3_qcom*qcom = platform_get_drvdata(pdev);
struct device_node  *np = pdev->dev.of_node, *dwc3_np;
struct device   *dev = >dev;
+   struct property *prop;
int ret;
 
dwc3_np = of_get_child_by_name(np, "dwc3");
@@ -642,6 +644,14 @@ static int dwc3_qcom_of_register_core(struct 
platform_device *pdev)
return -ENODEV;
}
 
+   prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+   if (prop) {
+   prop->name = "tx-fifo-resize";
+   ret = of_add_property(dwc3_np, prop);
+   if (ret < 0)
+   dev_info(dev, "unable to add tx-fifo-resize prop\n");
+   }
+
ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to register dwc3 core - %d\n", ret);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 3/5] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

Some devices have USB compositions which may require multiple endpoints
that support EP bursting.  HW defined TX FIFO sizes may not always be
sufficient for these compositions.  By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth.  With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.

By introducing the check_config() callback, the resizing logic can fetch
the maximum number of endpoints used in the USB composition (can contain
multiple configurations), which helps ensure that the resizing logic can
fulfill the configuration(s), or return an error to the gadget layer
otherwise during bind time.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/core.c   |   9 ++
 drivers/usb/dwc3/core.h   |  15 
 drivers/usb/dwc3/ep0.c|   2 +
 drivers/usb/dwc3/gadget.c | 214 ++
 4 files changed, 240 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 6969196..4f78370 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1238,6 +1238,7 @@ static void dwc3_get_properties(struct dwc3 *dwc)
u8  rx_max_burst_prd;
u8  tx_thr_num_pkt_prd;
u8  tx_max_burst_prd;
+   u8  tx_fifo_resize_max_num;
 
/* default to highest possible threshold */
lpm_nyet_threshold = 0xf;
@@ -1251,6 +1252,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
 */
hird_threshold = 12;
 
+   tx_fifo_resize_max_num = 6;
+
dwc->maximum_speed = usb_get_maximum_speed(dev);
dwc->dr_mode = usb_get_dr_mode(dev);
dwc->hsphy_mode = of_usb_get_phy_mode(dev->of_node);
@@ -1284,6 +1287,10 @@ static void dwc3_get_properties(struct dwc3 *dwc)
_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
_max_burst_prd);
+   dwc->do_fifo_resize = device_property_read_bool(dev,
+   "tx-fifo-resize");
+   device_property_read_u8(dev, "tx-fifo-max-num",
+   _fifo_resize_max_num);
 
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
@@ -1349,6 +1356,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
dwc->tx_max_burst_prd = tx_max_burst_prd;
 
dwc->imod_interval = 0;
+
+   dwc->tx_fifo_resize_max_num = tx_fifo_resize_max_num;
 }
 
 /* check whether the core supports IMOD */
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index eec1cf4..411b904 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1007,6 +1007,7 @@ struct dwc3_scratchpad_array {
  * @rx_max_burst_prd: max periodic ESS receive burst size
  * @tx_thr_num_pkt_prd: periodic ESS transmit packet count
  * @tx_max_burst_prd: max periodic ESS transmit burst size
+ * @tx_fifo_resize_max_num: max number of fifos allocated during txfifo resize
  * @hsphy_interface: "utmi" or "ulpi"
  * @connected: true when we're connected to a host, false otherwise
  * @delayed_status: true when gadget driver asks for delayed status
@@ -1062,6 +1063,11 @@ struct dwc3_scratchpad_array {
  * @dis_split_quirk: set to disable split boundary.
  * @imod_interval: set the interrupt moderation interval in 250ns
  * increments or 0 to disable.
+ * @max_cfg_eps: current max number of IN eps used across all USB configs.
+ * @last_fifo_depth: last fifo depth used to determine next fifo ram start
+ *  address.
+ * @num_ep_resized: carries the current number endpoints which have had its tx
+ * fifo resized.
  */
 struct dwc3 {
struct work_struct  drd_work;
@@ -1210,6 +1216,7 @@ struct dwc3 {
u8  rx_max_burst_prd;
u8  tx_thr_num_pkt_prd;
u8  tx_max_burst_prd;
+   u8  tx_fifo_resize_max_num;
 
const char  *hsphy_interface;
 
@@ -1223,6 +1230,7 @@ struct dwc3 {
unsignedis_utmi_l1_suspend:1;
unsignedis_fpga:1;
unsignedpending_events:1;
+   unsigneddo_fifo_resize:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
unsignedthree_stage_setup:1;
@@ -1257,6 +1265,10 @@ struct dwc3 {
unsigneddis_split_quirk:1;
 
u16 imod_interval;
+
+   int max_cfg_eps;
+   int last_fifo_depth;
+   int num_ep_resiz

[PATCH v7 1/5] usb: gadget: udc: core: Introduce check_config to verify USB configuration

[Wesley Cheng]

Some UDCs may have constraints on how many high bandwidth endpoints it can
support in a certain configuration.  This API allows for the composite
driver to pass down the total number of endpoints to the UDC so it can verify
it has the required resources to support the configuration.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/gadget/udc/core.c | 25 +
 include/linux/usb/gadget.h|  5 +
 2 files changed, 30 insertions(+)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 4173acd..81252e5 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1003,6 +1003,31 @@ int usb_gadget_ep_match_desc(struct usb_gadget *gadget,
 }
 EXPORT_SYMBOL_GPL(usb_gadget_ep_match_desc);
 
+/**
+ * usb_gadget_check_config - checks if the UDC can support the number of eps
+ * @gadget: controller to check the USB configuration
+ * @ep_map: bitmap of endpoints being requested by a USB configuration
+ *
+ * Ensure that a UDC is able to support the number of endpoints within a USB
+ * configuration, and that there are no resource limitations to support all
+ * requested eps.
+ *
+ * Returns zero on success, else a negative errno.
+ */
+int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long ep_map)
+{
+   int ret = 0;
+
+   if (!gadget->ops->check_config)
+   goto out;
+
+   ret = gadget->ops->check_config(gadget, ep_map);
+
+out:
+   return ret;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_check_config);
+
 /* - */
 
 static void usb_gadget_state_work(struct work_struct *work)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index ee04ef2..9fb69eb 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -328,6 +328,7 @@ struct usb_gadget_ops {
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
+   int (*check_config)(struct usb_gadget *gadget, unsigned long 
ep_map);
 };
 
 /**
@@ -607,6 +608,7 @@ int usb_gadget_connect(struct usb_gadget *gadget);
 int usb_gadget_disconnect(struct usb_gadget *gadget);
 int usb_gadget_deactivate(struct usb_gadget *gadget);
 int usb_gadget_activate(struct usb_gadget *gadget);
+int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long ep_map);
 #else
 static inline int usb_gadget_frame_number(struct usb_gadget *gadget)
 { return 0; }
@@ -630,6 +632,9 @@ static inline int usb_gadget_deactivate(struct usb_gadget 
*gadget)
 { return 0; }
 static inline int usb_gadget_activate(struct usb_gadget *gadget)
 { return 0; }
+static inline int usb_gadget_check_config(struct usb_gadget *gadget,
+ unsigned long ep_map)
+{ return 0; }
 #endif /* CONFIG_USB_GADGET */
 
 /*-*/
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 0/5] Re-introduce TX FIFO resize for larger EP bursting

[Wesley Cheng]

Changes in V7:
 - Added a new property tx-fifo-max-num for limiting how much fifo space the
   resizing logic can allocate for endpoints with large burst values.  This
   can differ across platforms, and tie in closely with overall system latency.
 - Added recommended checks for DWC32.
 - Added changes to set the tx-fifo-resize property from dwc3-qcom by default
   instead of modifying the current DTSI files.
 - Added comments on all APIs/variables introduced.
 - Updated the DWC3 YAML to include a better description of the tx-fifo-resize
   property and added an entry for tx-fifo-max-num.

Changes in V6:
 - Rebased patches to usb-testing.
 - Renamed to PATCH series instead of RFC.
 - Checking for fs_descriptors instead of ss_descriptors for determining the
   endpoint count for a particular configuration.
 - Re-ordered patch series to fix patch dependencies.

Changes in V5:
 - Added check_config() logic, which is used to communicate the number of EPs
   used in a particular configuration.  Based on this, the DWC3 gadget driver
   has the ability to know the maximum number of eps utilized in all configs.
   This helps reduce unnecessary allocation to unused eps, and will catch fifo
   allocation issues at bind() time.
 - Fixed variable declaration to single line per variable, and reverse xmas.
 - Created a helper for fifo clearing, which is used by ep0.c

Changes in V4:
 - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos()
 - Removed WARN_ON(1) in case we run out of fifo space
 
Changes in V3:
 - Removed "Reviewed-by" tags
 - Renamed series back to RFC
 - Modified logic to ensure that fifo_size is reset if we pass the minimum
   threshold.  Tested with binding multiple FDs requesting 6 FIFOs.

Changes in V2:
 - Modified TXFIFO resizing logic to ensure that each EP is reserved a
   FIFO.
 - Removed dev_dbg() prints and fixed typos from patches
 - Added some more description on the dt-bindings commit message

Currently, there is no functionality to allow for resizing the TXFIFOs, and
relying on the HW default setting for the TXFIFO depth.  In most cases, the
HW default is probably sufficient, but for USB compositions that contain
multiple functions that require EP bursting, the default settings
might not be enough.  Also to note, the current SW will assign an EP to a
function driver w/o checking to see if the TXFIFO size for that particular
EP is large enough. (this is a problem if there are multiple HW defined
values for the TXFIFO size)

It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3
is required for an EP that supports bursting.  Otherwise, there may be
frequent occurences of bursts ending.  For high bandwidth functions,
such as data tethering (protocols that support data aggregation), mass
storage, and media transfer protocol (over FFS), the bMaxBurst value can be
large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB
throughput. (which can be associated to system access latency, etc...)  It
allows for a more consistent burst of traffic, w/o any interruptions, as
data is readily available in the FIFO.

With testing done using the mass storage function driver, the results show
that with a larger TXFIFO depth, the bandwidth increased significantly.

Test Parameters:
 - Platform: Qualcomm SM8150
 - bMaxBurst = 6
 - USB req size = 256kB
 - Num of USB reqs = 16
 - USB Speed = Super-Speed
 - Function Driver: Mass Storage (w/ ramdisk)
 - Test Application: CrystalDiskMark

Results:

TXFIFO Depth = 3 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 193.60
  |   | 195.86
  |   | 184.77
  |   | 193.60
---

TXFIFO Depth = 6 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 287.35
  |   | 304.94
  |   | 289.64
  |   | 293.61
-------

Wesley Cheng (5):
  usb: gadget: udc: core: Introduce check_config to verify USB
configuration
  usb: gadget: configfs: Check USB configuration before adding
  usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
  usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default
  dt-bindings: usb: dwc3: Update dwc3 TX fifo properties

 .../devicetree/bindings/usb/snps,dwc3.yaml |  15 +-
 drivers/usb/dwc3/core.c|   9 +
 drivers/usb/dwc3/core.h|  15 ++
 drivers/usb/dwc3/dwc3-qcom.c   |  10 +
 drivers/usb/dwc3/ep0.c |   2 +
 drivers/usb/dwc3/gadget.c  | 214 +
 drivers/usb/gadget/configfs.c  |  22 +++
 drivers/usb/gadget/udc/core.c  |  25 +++
 include

Re: [PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

On 1/25/2021 9:15 PM, Bjorn Andersson wrote:
> On Mon 25 Jan 22:32 CST 2021, Wesley Cheng wrote:
>> On 1/25/2021 5:55 PM, Bjorn Andersson wrote:
>>> On Mon 25 Jan 19:14 CST 2021, Wesley Cheng wrote:
>>>
>>>>
>>>>
>>>> On 1/22/2021 9:12 AM, Bjorn Andersson wrote:
>>>>> On Thu 21 Jan 22:01 CST 2021, Wesley Cheng wrote:
>>>>>
>>>>
>>>> Hi Bjorn,
>>>>>
>>>>> Under what circumstances should we specify this? And in particular are
>>>>> there scenarios (in the Qualcomm platforms) where this must not be set?
>>>>> The TXFIFO dynamic allocation is actually a feature within the DWC3
>>>> controller, and isn't specifically for QCOM based platforms.  It won't
>>>> do any harm functionally if this flag is not set, as this is meant for
>>>> enhancing performance/bandwidth.
>>>>
>>>>> In particular, the composition can be changed in runtime, so should we
>>>>> set this for all Qualcomm platforms?
>>>>>
>>>> Ideally yes, if we want to increase bandwith for situations where SS
>>>> endpoint bursting is set to a higher value.
>>>>
>>>>> And if that's the case, can we not just set it from the qcom driver?
>>>>>
>>>> Since this is a common DWC3 core feature, I think it would make more
>>>> sense to have it in DWC3 core instead of a vendor's DWC3 glue driver.
>>>>
>>>
>>> I don't have any objections to implementing it in the core driver, but
>>> my question is can we just skip the DT binding and just enable it from
>>> the vendor driver?
>>>
>>> Regards,
>>> Bjorn
>>>
>>
>> Hi Bjorn,
>>
>> I see.  I think there are some designs which don't have a DWC3 glue
>> driver, so assuming there may be other platforms using this, there may
>> not always be a vendor driver to set this.
>>
> 
> You mean that there are implementations of dwc3 without an associated
> glue driver that haven't yet realized that they need this feature?
> 
> I would suggest then that we implement the core code necessary, we
> enable it from the Qualcomm glue layer and when someone realize that
> they need this without a glue driver it's going to be trivial to add the
> DT binding.
>>
> The alternative is that we're lugging around a requirement to specify
> this property in all past, present and future Qualcomm dts files - and
> then we'll need to hard code it for ACPI anyways.
> 
Hi Bjorn,

Can we utilize the of_add_property() call to add the "tx-fifo-resize"
property from the dwc3_qcom_register_core() API?  That way at least the
above concern would be addressed.

I'm not too familiar with the ACPI design, but I do see that the
dwc3-qcom does have an array carrying some DWC3 core properties.  Looks
like we can add the tx-fifo-resize property here too.

static const struct property_entry dwc3_qcom_acpi_properties[] = {
PROPERTY_ENTRY_STRING("dr_mode", "host"),
{}
};


Thanks
Wesley Cheng

> Regards,
> Bjorn
> 

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

Re: [Evergreen-general] Evergreen OPAC & Discovery Layers

[Wesley Custer]

We have just launched VuFind as our search layer for Evergreen. It searches
beautifully but the Evergreen integration needs some additional development
(holds and account management, for example).

Wesley Custer, MDiv, MABS, MSLIS
Director of Instructional Services
Asbury Theological Seminary
*A community called...*

Make a Research Appointment
<http://asburyseminary.libcal.com/appointment/355> | Schedule time in the
Studio <https://guides.asburyseminary.edu/studio> | Check out the Faculty
Resource Guide <https://asburyseminary.instructure.com/courses/43>



On Thu, Jan 28, 2021 at 9:28 AM Murphy, Benjamin 
wrote:

> NC Cardinal has implemented Summon for many of our library systems.
> Documentation here
> https://nccardinalsupport.org/index.php?pg=kb.book=11 including links
> to individual instances under the section 1. Individual Summon Links
> <https://nccardinalsupport.org/index.php?pg=kb.page=371>
>
> Benjamin
>
>
>
> *Benjamin Murphy*
>
> NC Cardinal Program Manager
>
> State Library of North Carolina
>
> 919.814.6797 |  *benjamin.mur...@ncdcr.gov  *
>
> https://statelibrary.ncdcr.gov/ld/nc-cardinal
>
>
> NC Dept. of Natural and Cultural Resources
>
> 109 East Jones Street  | 4640 Mail Service Center
>
> Raleigh, North Carolina 27699-4600
>
> Facebook <https://www.facebook.com/StateLibraryNC/>  Twitter
> <https://twitter.com/StateLibraryNC>  Instagram
> <http://www.instagram.com/ncculture>  YouTube
> <https://www.youtube.com/user/statelibrarync/>  Website
> <https://statelibrary.ncdcr.gov/>
>
>
>
> *Email correspondence to and from this address is subject to the North
> Carolina Public Records Law and may be disclosed to third parties.*
>
>
>
>
>
>
>
>
>
> On Fri, Jan 15, 2021 at 9:19 AM Frasur, Ruth 
> wrote:
>
> Is your library using a discovery layer w/ the Evergreen OPAC?  Is your
> library part of a consortium that uses a discovery layer?  Does your
> consortium include member libraries that MAY or MAY NOT use a discovery
> layer for their individual systems?
>
>
>
> If you’ve answered yes to any of these questions, I would love to hear
> more including what discovery layer you’re using (including if it’s a home
> brew solution).
>
>
>
> Ruth Frasur
>
> *Evergreen Development and Support Administrator*
>
> Indiana State Library
>
> 140 N. Senate Ave.
>
> Indianapolis, IN 46204
>
> (317) 460-7556
>
>
>
> ___
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
> <https://urldefense.com/v3/__http:/list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general__;!!HYmSToo!KNEd6j4Z_d9Ou8HciBX_ZjN57x-vRzRk-Wa3IwAZ8F1B-TF6Drwha7xfa9v6DmY4bmdkYdE$>
>
> ___
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

On 1/26/2021 12:43 PM, Thinh Nguyen wrote:
> Wesley Cheng wrote:
>>
>> On 1/22/2021 4:15 PM, Thinh Nguyen wrote:
>>> Hi,
>>>
>>> Wesley Cheng wrote:
>>>> Some devices have USB compositions which may require multiple endpoints
>>>> that support EP bursting.  HW defined TX FIFO sizes may not always be
>>>> sufficient for these compositions.  By utilizing flexible TX FIFO
>>>> allocation, this allows for endpoints to request the required FIFO depth to
>>>> achieve higher bandwidth.  With some higher bMaxBurst configurations, using
>>>> a larger TX FIFO size results in better TX throughput.
>>>>
>>>> By introducing the check_config() callback, the resizing logic can fetch
>>>> the maximum number of endpoints used in the USB composition (can contain
>>>> multiple configurations), which helps ensure that the resizing logic can
>>>> fulfill the configuration(s), or return an error to the gadget layer
>>>> otherwise during bind time.
>>>>
>>>> Signed-off-by: Wesley Cheng 
>>>> ---
>>>>  drivers/usb/dwc3/core.c   |   2 +
>>>>  drivers/usb/dwc3/core.h   |   8 ++
>>>>  drivers/usb/dwc3/ep0.c|   2 +
>>>>  drivers/usb/dwc3/gadget.c | 194 
>>>> ++
>>>>  4 files changed, 206 insertions(+)
>>>>
>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>> index 6969196..e7fa6af 100644
>>>> --- a/drivers/usb/dwc3/core.c
>>>> +++ b/drivers/usb/dwc3/core.c
>>>> @@ -1284,6 +1284,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
>>>>_thr_num_pkt_prd);
>>>>device_property_read_u8(dev, "snps,tx-max-burst-prd",
>>>>_max_burst_prd);
>>>> +  dwc->needs_fifo_resize = device_property_read_bool(dev,
>>>> + "tx-fifo-resize");
>>>>  
>>>>dwc->disable_scramble_quirk = device_property_read_bool(dev,
>>>>"snps,disable_scramble_quirk");
>>>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>>>> index eec1cf4..983b2fd4 100644
>>>> --- a/drivers/usb/dwc3/core.h
>>>> +++ b/drivers/usb/dwc3/core.h
>>>> @@ -1223,6 +1223,7 @@ struct dwc3 {
>>>>unsignedis_utmi_l1_suspend:1;
>>>>unsignedis_fpga:1;
>>>>unsignedpending_events:1;
>>>> +  unsignedneeds_fifo_resize:1;
>>> The prefix "need" sounds like a requirement, but I don't think it is the
>>> case here. I think "do" would be a better prefix here.
>>>
>> Hi Thinh,
>>
>> Sure, that is true, since this may be an optional flag for certain
>> platforms.
>>
>>>>unsignedpullups_connected:1;
>>>>unsignedsetup_packet_pending:1;
>>>>unsignedthree_stage_setup:1;
>>>> @@ -1257,6 +1258,10 @@ struct dwc3 {
>>>>unsigneddis_split_quirk:1;
>>>>  
>>>>u16 imod_interval;
>>>> +
>>>> +  int max_cfg_eps;
>>>> +  int last_fifo_depth;
>>>> +  int num_ep_resized;
>>>>  };
>>> Please document these new fields.
>>>
>> Will do.
>>
>>>>  
>>>>  #define INCRX_BURST_MODE 0
>>>> @@ -1471,6 +1476,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, 
>>>> unsigned int cmd,
>>>>struct dwc3_gadget_ep_cmd_params *params);
>>>>  int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned int cmd,
>>>>u32 param);
>>>> +void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc);
>>>>  #else
>>>>  static inline int dwc3_gadget_init(struct dwc3 *dwc)
>>>>  { return 0; }
>>>> @@ -1490,6 +1496,8 @@ static inline int dwc3_send_gadget_ep_cmd(struct 
>>>> dwc3_ep *dep, unsigned int cmd,
>>>>  static inline int dwc3_send_gadget_generic_command(struct dwc3 *dwc,
>>>>int cmd, u32 param)
>>>>  { return 0; }
>>>> +static inline void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
>>>> +{ }
>>>>  #

Re: usb: dwc3: gadget: skip pullup and set_speed after suspend

[Wesley Cheng]

On 1/21/2021 11:15 PM, Jung Daehwan wrote:
> On Fri, Jan 22, 2021 03:32, Wesley cheng wrote:
>> Hi Daehwan,
>>
>> If this is an unexpected event where userspace initiates the UDC bind
>> sequence, then after the above sequence occurs, the DWC3 device should
>> still be able to re-enter runtime suspend after the autosuspend timer
>> expires.  Since the cable is disconnected, the dwc->connected flag would
>> still be false.  Is this not happening in your situation?
>>
>> I'm just trying to understand what issue you're seeing other than the
>> momentary transition from runtime suspend (due to cable disconnect)
>> -->runtime resume (due to unexpected UDC bind) --> runtime  suspend (due
>> to nothing connected).
>>
>> Thanks
>> Wesley cheng
> 
> Hi Wesley,
> 
> I don't know why but DWC3 device is not re-entering runtime-suspend in
> my situation. I'm still debugging it.
> Even if DWC3 re-enter runtime-suspend but it doesn't mean stopping gadget.
> Are you stopping gadget manually in this case?

Hi Daehwan,

Sorry for the late response.  So during the DWC3 runtime suspend path,
we will execute dwc3_gadget_suspend() which should disable the gadget
events and disable ep0 then clear RS bit.  Then on runtime resume, the
DWC3 will be re-enabled, and the RS bit set again.

Thanks
Wesley Cheng

> 
> Best Regards,
> Jung Daehwan
> 
> 

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

Re: perl's pulsar client

[Wesley Peng]

I am looking for a native client library since there is the functions more than 
publish/consume I want.

Thanks.

On Wed, Jan 27, 2021, at 9:19 AM, Mithun Bhattacharya wrote:
> This seems to demonstrate Pulsar with mojo.
> 
> https://www.perlmonks.org/?node_id=11123636
> 
> On Tue, Jan 26, 2021, 7:09 PM Wesley Peng  wrote:
>> __
>> I saw apache pulsar has many clients in other languages such as python's:
>> http://pulsar.apache.org/docs/en/client-libraries-python/
>> 
>> But it lacks a perl client library.
>> Would anyone have the plan to make one?
>> 
>> Thanks.

perl's pulsar client

[Wesley Peng]

I saw apache pulsar has many clients in other languages such as python's:
http://pulsar.apache.org/docs/en/client-libraries-python/

But it lacks a perl client library.
Would anyone have the plan to make one?

Thanks.

perl's pulsar client

[Wesley Peng]

I saw apache pulsar has many clients in other languages such as python's:
http://pulsar.apache.org/docs/en/client-libraries-python/

But it lacks a perl client library.
Would anyone have the plan to make one?

Thanks.

Re: [PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

On 1/22/2021 4:15 PM, Thinh Nguyen wrote:
> Hi,
> 
> Wesley Cheng wrote:
>> Some devices have USB compositions which may require multiple endpoints
>> that support EP bursting.  HW defined TX FIFO sizes may not always be
>> sufficient for these compositions.  By utilizing flexible TX FIFO
>> allocation, this allows for endpoints to request the required FIFO depth to
>> achieve higher bandwidth.  With some higher bMaxBurst configurations, using
>> a larger TX FIFO size results in better TX throughput.
>>
>> By introducing the check_config() callback, the resizing logic can fetch
>> the maximum number of endpoints used in the USB composition (can contain
>> multiple configurations), which helps ensure that the resizing logic can
>> fulfill the configuration(s), or return an error to the gadget layer
>> otherwise during bind time.
>>
>> Signed-off-by: Wesley Cheng 
>> ---
>>  drivers/usb/dwc3/core.c   |   2 +
>>  drivers/usb/dwc3/core.h   |   8 ++
>>  drivers/usb/dwc3/ep0.c|   2 +
>>  drivers/usb/dwc3/gadget.c | 194 
>> ++
>>  4 files changed, 206 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 6969196..e7fa6af 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1284,6 +1284,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
>>  _thr_num_pkt_prd);
>>  device_property_read_u8(dev, "snps,tx-max-burst-prd",
>>  _max_burst_prd);
>> +dwc->needs_fifo_resize = device_property_read_bool(dev,
>> +   "tx-fifo-resize");
>>  
>>  dwc->disable_scramble_quirk = device_property_read_bool(dev,
>>  "snps,disable_scramble_quirk");
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index eec1cf4..983b2fd4 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -1223,6 +1223,7 @@ struct dwc3 {
>>  unsignedis_utmi_l1_suspend:1;
>>  unsignedis_fpga:1;
>>  unsignedpending_events:1;
>> +unsignedneeds_fifo_resize:1;
> 
> The prefix "need" sounds like a requirement, but I don't think it is the
> case here. I think "do" would be a better prefix here.
> 
Hi Thinh,

Sure, that is true, since this may be an optional flag for certain
platforms.

>>  unsignedpullups_connected:1;
>>  unsignedsetup_packet_pending:1;
>>  unsignedthree_stage_setup:1;
>> @@ -1257,6 +1258,10 @@ struct dwc3 {
>>  unsigneddis_split_quirk:1;
>>  
>>  u16 imod_interval;
>> +
>> +int max_cfg_eps;
>> +int last_fifo_depth;
>> +int num_ep_resized;
>>  };
> 
> Please document these new fields.
> 
Will do.

>>  
>>  #define INCRX_BURST_MODE 0
>> @@ -1471,6 +1476,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, 
>> unsigned int cmd,
>>  struct dwc3_gadget_ep_cmd_params *params);
>>  int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned int cmd,
>>  u32 param);
>> +void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc);
>>  #else
>>  static inline int dwc3_gadget_init(struct dwc3 *dwc)
>>  { return 0; }
>> @@ -1490,6 +1496,8 @@ static inline int dwc3_send_gadget_ep_cmd(struct 
>> dwc3_ep *dep, unsigned int cmd,
>>  static inline int dwc3_send_gadget_generic_command(struct dwc3 *dwc,
>>  int cmd, u32 param)
>>  { return 0; }
>> +static inline void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
>> +{ }
>>  #endif
>>  
>>  #if IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index 8b668ef..4f216bd 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
>> @@ -616,6 +616,8 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
>> usb_ctrlrequest *ctrl)
>>  return -EINVAL;
>>  
>>  case USB_STATE_ADDRESS:
>> +dwc3_gadget_clear_tx_fifos(dwc);
>> +
>>  ret = dwc3_ep0_delegate_req(dwc, ctrl);
>>  /* if the cfg matches and the cfg is non zero */
>>  if (cfg && (!ret || (ret == USB_GADGET_DELAYED_STATUS))) {
>&g

Re: [PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

On 1/25/2021 5:55 PM, Bjorn Andersson wrote:
> On Mon 25 Jan 19:14 CST 2021, Wesley Cheng wrote:
> 
>>
>>
>> On 1/22/2021 9:12 AM, Bjorn Andersson wrote:
>>> On Thu 21 Jan 22:01 CST 2021, Wesley Cheng wrote:
>>>
>>
>> Hi Bjorn,
>>>
>>> Under what circumstances should we specify this? And in particular are
>>> there scenarios (in the Qualcomm platforms) where this must not be set?
>>> The TXFIFO dynamic allocation is actually a feature within the DWC3
>> controller, and isn't specifically for QCOM based platforms.  It won't
>> do any harm functionally if this flag is not set, as this is meant for
>> enhancing performance/bandwidth.
>>
>>> In particular, the composition can be changed in runtime, so should we
>>> set this for all Qualcomm platforms?
>>>
>> Ideally yes, if we want to increase bandwith for situations where SS
>> endpoint bursting is set to a higher value.
>>
>>> And if that's the case, can we not just set it from the qcom driver?
>>>
>> Since this is a common DWC3 core feature, I think it would make more
>> sense to have it in DWC3 core instead of a vendor's DWC3 glue driver.
>>
> 
> I don't have any objections to implementing it in the core driver, but
> my question is can we just skip the DT binding and just enable it from
> the vendor driver?
> 
> Regards,
> Bjorn
> 

Hi Bjorn,

I see.  I think there are some designs which don't have a DWC3 glue
driver, so assuming there may be other platforms using this, there may
not always be a vendor driver to set this.

Thanks
Wesley Cheng

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

Re: [Emc-users] Maybe a minimally printed harmonic drive?

[Sven Wesley]

Den tis 26 jan. 2021 kl 05:47 skrev Sam Sokolik :

> I am sure the torque is limited - but I feel it might have possibility...
>
> https://www.youtube.com/watch?v=QlpkmEEhFqc
>
>
I can totally see that drive on my home made trunnion table!

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

Re: [PATCH v6 1/4] usb: gadget: udc: core: Introduce check_config to verify USB configuration

[Wesley Cheng]

On 1/21/2021 9:17 PM, Jack Pham wrote:
> Hi Wesley,
> 
> On Thu, Jan 21, 2021 at 08:01:37PM -0800, Wesley Cheng wrote:
>> Some UDCs may have constraints on how many high bandwidth endpoints it can
>> support in a certain configuration.  This API allows for the composite
>> driver to pass down the total number of endpoints to the UDC so it can verify
>> it has the required resources to support the configuration.
>>
>> Signed-off-by: Wesley Cheng 
>> ---
>>  drivers/usb/gadget/udc/core.c | 9 +
>>  include/linux/usb/gadget.h| 2 ++
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
>> index 4173acd..469962f 100644
>> --- a/drivers/usb/gadget/udc/core.c
>> +++ b/drivers/usb/gadget/udc/core.c
>> @@ -1003,6 +1003,15 @@ int usb_gadget_ep_match_desc(struct usb_gadget 
>> *gadget,
>>  }
>>  EXPORT_SYMBOL_GPL(usb_gadget_ep_match_desc);
>>  
>> +int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long ep_map)
> 
> You should probably add a kernel-doc for this function.
> 
> Jack
> 
Hi Jack,

Sure, I'll update a bit more about how this API can be used.

Thanks
Wesley Cheng

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

Re: [PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

On 1/22/2021 9:12 AM, Bjorn Andersson wrote:
> On Thu 21 Jan 22:01 CST 2021, Wesley Cheng wrote:
> 

Hi Bjorn,
> 
> Under what circumstances should we specify this? And in particular are
> there scenarios (in the Qualcomm platforms) where this must not be set?
>The TXFIFO dynamic allocation is actually a feature within the DWC3
controller, and isn't specifically for QCOM based platforms.  It won't
do any harm functionally if this flag is not set, as this is meant for
enhancing performance/bandwidth.

> In particular, the composition can be changed in runtime, so should we
> set this for all Qualcomm platforms?
> 
Ideally yes, if we want to increase bandwith for situations where SS
endpoint bursting is set to a higher value.

> And if that's the case, can we not just set it from the qcom driver?
> 
Since this is a common DWC3 core feature, I think it would make more
sense to have it in DWC3 core instead of a vendor's DWC3 glue driver.

Thanks
Wesley Cheng

> Regards,
> Bjorn


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

Re: [PATCH v6 1/4] usb: gadget: udc: core: Introduce check_config to verify USB configuration

[Wesley Cheng]

On 1/22/2021 8:24 AM, Alan Stern wrote:
> On Thu, Jan 21, 2021 at 08:01:37PM -0800, Wesley Cheng wrote:
>> Some UDCs may have constraints on how many high bandwidth endpoints it can
>> support in a certain configuration.  This API allows for the composite
>> driver to pass down the total number of endpoints to the UDC so it can verify
>> it has the required resources to support the configuration.
>>
>> Signed-off-by: Wesley Cheng 
> 
> 
>> --- a/include/linux/usb/gadget.h
>> +++ b/include/linux/usb/gadget.h
>> @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>>  struct usb_ep *(*match_ep)(struct usb_gadget *,
>>  struct usb_endpoint_descriptor *,
>>  struct usb_ss_ep_comp_descriptor *);
>> +int (*check_config)(struct usb_gadget *gadget, unsigned long 
>> ep_map);
>>  };
>>  
>>  /**
>> @@ -607,6 +608,7 @@ int usb_gadget_connect(struct usb_gadget *gadget);
>>  int usb_gadget_disconnect(struct usb_gadget *gadget);
>>  int usb_gadget_deactivate(struct usb_gadget *gadget);
>>  int usb_gadget_activate(struct usb_gadget *gadget);
>> +int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long 
>> ep_map);
>>  #else
>>  static inline int usb_gadget_frame_number(struct usb_gadget *gadget)
>>  { return 0; }
> 
> Don't you also need an entry for the case where CONFIG_USB_GADGET isn't 
> enabled?
> 
> Alan Stern
> 
Hi Alan,

Thanks for pointing that out.  I missed that, and will add it to the
next rev.

Thanks
Wesley Cheng


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

Re: [Mpi-forum] FTWG Con Call Today

[Wesley Bland via mpi-forum]

Hi all,

After talking to Tony, we're going to delay this discussion until the next
call on Feb 8. Today's call is cancelled.

Thanks,
Wes

On Mon, Jan 25, 2021 at 8:15 AM w...@wesbland.com  wrote:

> The Fault Tolerance Working Group’s weekly con call is today at 12:00 PM
> Eastern. Today's agenda:
>
>
>
> * FA-MPI (Tony)
>
> * Other updates (All)
>
>
>
> If there's something else that people would like to discuss, please just
> send an email to the WG so we can get it on the agenda.
>
>
>
> Thanks,
>
> Wes
>
>
>
> ...
>
>
> Join from PC, Mac, Linux, iOS or Android:
> https://tennessee.zoom.us/j/632356722?pwd=lI4_169CGcewIumekTziMw
>
> Password: mpiforum
>
>
>
> Or iPhone one-tap (US Toll):  +16468769923,632356722#  or
> +16699006833,632356722#
>
>
>
> Or Telephone:
>
> Dial:
>
> +1 646 876 9923 (US Toll)
>
> +1 669 900 6833 (US Toll)
>
> Meeting ID: 632 356 722
>
> International numbers available: https://zoom.us/u/6uINe
>
>
>
> Or an H.323/SIP room system:
>
> H.323: 162.255.37.11 (US West) or 162.255.36.11 (US East)
>
> Meeting ID: 632 356 722
>
> Password: 364216
>
>
>
> SIP: 632356...@zoomcrc.com
>
> Password: 364216
>
>
> ...
>
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Emc-users] hi guys

[Sven Wesley]

Den tors 14 jan. 2021 kl 23:28 skrev andrew beck :

> I have some proxy switches on my cnc lathe I am retrofitting and have a few
> questions
>
> the switches are omron 10-40v dc and NPN NO
> basically opposite to what i need I think lol.
> I think the mesa cards prefer PNP NC proxy switches
> anyway I saw on the forum that you can use a resistor to interface with the
> npn proxies.
>
>
> https://www.forum.linuxcnc.org/27-driver-boards/27877-mesa-cards-and-inductive-proximity-switches?start=10
>
> PCW mentioned a 2K 1 W pullup to 24V
> I just wanted to send a quick email asking about this.  before I connect up
> and blow something always good to check first here
>
> regards
> Andrew
>


Here's a link to Norbert's Mesa wiring PDF. It has an example page with
prox sensors.
https://forum.linuxcnc.org/media/kunena/attachments/3278/7i76_Anschluss_2016-12-03.pdf

Regards,
Sven

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

[PATCH v3 1/2] lib/cmdline: add new function get_option_ull()

[Wesley Zhao]

In the future we would pass the unsigned long long parameter
like(0x123456781234) in cmdline on the 64bit platform, so add a new
option parse function get_option_ull()

Signed-off-by: Wesley Zhao 
---
 include/linux/kernel.h |  2 ++
 lib/cmdline.c  | 94 ++
 2 files changed, 82 insertions(+), 14 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f7902d8c1048..eb1f0b14a0c5 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -348,6 +348,8 @@ extern __scanf(2, 0)
 int vsscanf(const char *, const char *, va_list);
 
 extern int get_option(char **str, int *pint);
+extern int get_option_ll(char **str, long long *pll);
+extern int get_option_ull(char **str, unsigned long long *pull);
 extern char *get_options(const char *str, int nints, int *ints);
 extern unsigned long long memparse(const char *ptr, char **retptr);
 extern bool parse_option_str(const char *str, const char *option);
diff --git a/lib/cmdline.c b/lib/cmdline.c
index b390dd03363b..6030fc70e0f5 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -31,6 +31,81 @@ static int get_range(char **str, int *pint, int n)
*pint++ = x;
return inc_counter;
 }
+/**
+ * get_option_ull - Parse unsigned long long from an option string
+ * @str: option string
+ * @pull: (output) unsigned long long value parsed from @str
+ *
+ * Read an unsigned long long from an option string; if available accept a 
subsequent
+ * comma as well.
+ *
+ * Return values:
+ * 0 - no ull in string
+ * 1 - ull found, no subsequent comma
+ * 2 - ull found including a subsequent comma
+ * 3 - hyphen found to denote a range
+ */
+
+int get_option_ull(char **str, unsigned long long *pull)
+{
+   char *cur = *str;
+   unsigned long long value;
+
+   if (!cur || !(*cur))
+   return 0;
+   value = simple_strtoull(cur, str, 0);
+   if (pull)
+   *pull = value;
+   if (cur == *str)
+   return 0;
+   if (**str == ',') {
+   (*str)++;
+   return 2;
+   }
+   if (**str == '-')
+   return 3;
+
+   return 1;
+}
+EXPORT_SYMBOL(get_option_ull);
+
+/**
+ * get_option_ll - Parse long long from an option string
+ * @str: option string
+ * @pll: (output) long long value parsed from @str
+ *
+ * Read an long long from an option string; if available accept a 
subsequent
+ * comma as well.
+ *
+ * Return values:
+ * 0 - no ll in string
+ * 1 - ll found, no subsequent comma
+ * 2 - ll found including a subsequent comma
+ * 3 - hyphen found to denote a range
+ */
+
+int get_option_ll(char **str, long long *pll)
+{
+   char *cur = *str;
+   unsigned long long value;
+   int ret;
+
+   if (!cur || !(*cur))
+   return 0;
+   if (*cur == '-') {
+   (*str) = cur + 1;
+   ret = get_option_ull(str, );
+   if (pll)
+   *pll = -value;
+   } else {
+   ret = get_option_ull(str, );
+   if (pll)
+   *pll = value;
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL(get_option_ll);
 
 /**
  * get_option - Parse integer from an option string
@@ -56,26 +131,17 @@ static int get_range(char **str, int *pint, int n)
 int get_option(char **str, int *pint)
 {
char *cur = *str;
-   int value;
+   long long value;
+   int ret;
 
if (!cur || !(*cur))
return 0;
-   if (*cur == '-')
-   value = -simple_strtoull(++cur, str, 0);
-   else
-   value = simple_strtoull(cur, str, 0);
+   ret = get_option_ll(str, );
+
if (pint)
*pint = value;
-   if (cur == *str)
-   return 0;
-   if (**str == ',') {
-   (*str)++;
-   return 2;
-   }
-   if (**str == '-')
-   return 3;
 
-   return 1;
+   return ret;
 }
 EXPORT_SYMBOL(get_option);
 
-- 
2.7.4

[PATCH v3 2/2] resource: Make it possible to reserve memory on 64bit platform

[Wesley Zhao]

For now "reserve=" is limitied to 32bit,not available on 64bit
platform,so we change the get_option() to get_option_ull(added in
patch: commit 4b6bfe96265e ("lib/cmdline: add new function
get_option_ull()"))

Signed-off-by: Wesley Zhao 
---
 kernel/resource.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 833394f9c608..ee2a0e5d196f 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1567,13 +1567,13 @@ static int __init reserve_setup(char *str)
static struct resource reserve[MAXRESERVE];
 
for (;;) {
-   unsigned int io_start, io_num;
+   unsigned long long io_start, io_num;
int x = reserved;
struct resource *parent;
 
-   if (get_option(, _start) != 2)
+   if (get_option_ull(, _start) != 2)
break;
-   if (get_option(, _num) == 0)
+   if (get_option_ull(, _num) == 0)
break;
if (x < MAXRESERVE) {
struct resource *res = reserve + x;
-- 
2.7.4

[PATCH v3 0/2] Make it possible to reserve memory on 64bit platform

[Wesley Zhao]

I was trying to reserve some memory to save logs incase that Android panic or 
hang and then
I can read the logs from QNX side from the memory reserved before on the 
Qualcomm 8155 hypervisor platform,
and I find the "reserve=" parameter only support 32bit,so I made some change 
and send these patches.

I run the cmdline_kunit.c and got these:
[1.663048] 1..1
[1.663107] # Subtest: cmdline
[1.663145] 1..3
[1.663795] ok 1 - cmdline_test_noint
[1.664139] ok 2 - cmdline_test_lead_int
[1.664553] ok 3 - cmdline_test_tail_int
[1.664788] ok 1 - cmdline

Additionaly:
I test on the qemu with some cmdline like[qemu-system-x86_64 -kernel 
linux-next/arch/x86_64/boot/bzImage
-hda ubuntu-system.ext4 -append "root=/dev/sda init=/bin/bash 
console=ttyS0 reserve=0x18000,0x123456"
-nographic] and check the /proc/iomem with 18000-180123455 : 
reserved.
And some other tests with the get_option with the parameter(-12345678) 
and so on


Wesley Zhao (2):
  lib/cmdline: add new function get_option_ull()
  resource: Make it possible to reserve memory on 64bit platform

 include/linux/kernel.h |  2 ++
 kernel/resource.c  |  6 ++--
 lib/cmdline.c  | 94 ++
 3 files changed, 85 insertions(+), 17 deletions(-)

-- 
2.7.4

[PATCH v6 0/4] Re-introduce TX FIFO resize for larger EP bursting

[Wesley Cheng]

Changes in V6:
 - Rebased patches to usb-testing.
 - Renamed to PATCH series instead of RFC.
 - Checking for fs_descriptors instead of ss_descriptors for determining the
   endpoint count for a particular configuration.
 - Re-ordered patch series to fix patch dependencies.

Changes in V5:
 - Added check_config() logic, which is used to communicate the number of EPs
   used in a particular configuration.  Based on this, the DWC3 gadget driver
   has the ability to know the maximum number of eps utilized in all configs.
   This helps reduce unnecessary allocation to unused eps, and will catch fifo
   allocation issues at bind() time.
 - Fixed variable declaration to single line per variable, and reverse xmas.
 - Created a helper for fifo clearing, which is used by ep0.c

Changes in V4:
 - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos()
 - Removed WARN_ON(1) in case we run out of fifo space
 
Changes in V3:
 - Removed "Reviewed-by" tags
 - Renamed series back to RFC
 - Modified logic to ensure that fifo_size is reset if we pass the minimum
   threshold.  Tested with binding multiple FDs requesting 6 FIFOs.

Changes in V2:
 - Modified TXFIFO resizing logic to ensure that each EP is reserved a
   FIFO.
 - Removed dev_dbg() prints and fixed typos from patches
 - Added some more description on the dt-bindings commit message

Currently, there is no functionality to allow for resizing the TXFIFOs, and
relying on the HW default setting for the TXFIFO depth.  In most cases, the
HW default is probably sufficient, but for USB compositions that contain
multiple functions that require EP bursting, the default settings
might not be enough.  Also to note, the current SW will assign an EP to a
function driver w/o checking to see if the TXFIFO size for that particular
EP is large enough. (this is a problem if there are multiple HW defined
values for the TXFIFO size)

It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3
is required for an EP that supports bursting.  Otherwise, there may be
frequent occurences of bursts ending.  For high bandwidth functions,
such as data tethering (protocols that support data aggregation), mass
storage, and media transfer protocol (over FFS), the bMaxBurst value can be
large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB
throughput. (which can be associated to system access latency, etc...)  It
allows for a more consistent burst of traffic, w/o any interruptions, as
data is readily available in the FIFO.

With testing done using the mass storage function driver, the results show
that with a larger TXFIFO depth, the bandwidth increased significantly.

Test Parameters:
 - Platform: Qualcomm SM8150
 - bMaxBurst = 6
 - USB req size = 256kB
 - Num of USB reqs = 16
 - USB Speed = Super-Speed
 - Function Driver: Mass Storage (w/ ramdisk)
 - Test Application: CrystalDiskMark

Results:

TXFIFO Depth = 3 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 193.60
  |   | 195.86
  |   | 184.77
  |   | 193.60
---

TXFIFO Depth = 6 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 287.35
  |   | 304.94
  |   | 289.64
  |   | 293.61
-------
Wesley Cheng (4):
  usb: gadget: udc: core: Introduce check_config to verify USB
configuration
  usb: gadget: configfs: Check USB configuration before adding
  usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
  arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic

 arch/arm64/boot/dts/qcom/sm8150.dtsi |   1 +
 drivers/usb/dwc3/core.c  |   2 +
 drivers/usb/dwc3/core.h  |   8 ++
 drivers/usb/dwc3/ep0.c   |   2 +
 drivers/usb/dwc3/gadget.c| 194 +++
 drivers/usb/gadget/configfs.c|  22 
 drivers/usb/gadget/udc/core.c|   9 ++
 include/linux/usb/gadget.h   |   2 +
 8 files changed, 240 insertions(+)

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

[PATCH v6 1/4] usb: gadget: udc: core: Introduce check_config to verify USB configuration

[Wesley Cheng]

Some UDCs may have constraints on how many high bandwidth endpoints it can
support in a certain configuration.  This API allows for the composite
driver to pass down the total number of endpoints to the UDC so it can verify
it has the required resources to support the configuration.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/gadget/udc/core.c | 9 +
 include/linux/usb/gadget.h| 2 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 4173acd..469962f 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1003,6 +1003,15 @@ int usb_gadget_ep_match_desc(struct usb_gadget *gadget,
 }
 EXPORT_SYMBOL_GPL(usb_gadget_ep_match_desc);
 
+int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long ep_map)
+{
+   if (!gadget->ops->check_config)
+   return 0;
+
+   return gadget->ops->check_config(gadget, ep_map);
+}
+EXPORT_SYMBOL_GPL(usb_gadget_check_config);
+
 /* - */
 
 static void usb_gadget_state_work(struct work_struct *work)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index ee04ef2..8393fa8 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -328,6 +328,7 @@ struct usb_gadget_ops {
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
+   int (*check_config)(struct usb_gadget *gadget, unsigned long 
ep_map);
 };
 
 /**
@@ -607,6 +608,7 @@ int usb_gadget_connect(struct usb_gadget *gadget);
 int usb_gadget_disconnect(struct usb_gadget *gadget);
 int usb_gadget_deactivate(struct usb_gadget *gadget);
 int usb_gadget_activate(struct usb_gadget *gadget);
+int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long ep_map);
 #else
 static inline int usb_gadget_frame_number(struct usb_gadget *gadget)
 { return 0; }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v6 2/4] usb: gadget: configfs: Check USB configuration before adding

[Wesley Cheng]

Ensure that the USB gadget is able to support the configuration being
added based on the number of endpoints required from all interfaces.  This
is for accounting for any bandwidth or space limitations.

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

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 0d56f33..e6de3ca5 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1368,6 +1368,7 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
struct usb_function *f;
struct usb_function *tmp;
struct gadget_config_name *cn;
+   unsigned long ep_map = 0;
 
if (gadget_is_otg(gadget))
c->descriptors = otg_desc;
@@ -1397,7 +1398,28 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
list_add(>list, >func_list);
goto err_purge_funcs;
}
+   if (f->fs_descriptors) {
+   struct usb_descriptor_header **d;
+
+   d = f->fs_descriptors;
+   for (; *d; ++d) {
+   struct usb_endpoint_descriptor *ep;
+   int addr;
+
+   if ((*d)->bDescriptorType != 
USB_DT_ENDPOINT)
+   continue;
+
+   ep = (struct usb_endpoint_descriptor 
*)*d;
+   addr = ((ep->bEndpointAddress & 0x80) 
>> 3) |
+   (ep->bEndpointAddress & 0x0f);
+   set_bit(addr, _map);
+   }
+   }
}
+   ret = usb_gadget_check_config(cdev->gadget, ep_map);
+   if (ret)
+   goto err_purge_funcs;
+
usb_ep_autoconfig_reset(cdev->gadget);
}
if (cdev->use_os_string) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

Some devices have USB compositions which may require multiple endpoints
that support EP bursting.  HW defined TX FIFO sizes may not always be
sufficient for these compositions.  By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth.  With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.

By introducing the check_config() callback, the resizing logic can fetch
the maximum number of endpoints used in the USB composition (can contain
multiple configurations), which helps ensure that the resizing logic can
fulfill the configuration(s), or return an error to the gadget layer
otherwise during bind time.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/core.c   |   2 +
 drivers/usb/dwc3/core.h   |   8 ++
 drivers/usb/dwc3/ep0.c|   2 +
 drivers/usb/dwc3/gadget.c | 194 ++
 4 files changed, 206 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 6969196..e7fa6af 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1284,6 +1284,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
_max_burst_prd);
+   dwc->needs_fifo_resize = device_property_read_bool(dev,
+  "tx-fifo-resize");
 
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index eec1cf4..983b2fd4 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1223,6 +1223,7 @@ struct dwc3 {
unsignedis_utmi_l1_suspend:1;
unsignedis_fpga:1;
unsignedpending_events:1;
+   unsignedneeds_fifo_resize:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
unsignedthree_stage_setup:1;
@@ -1257,6 +1258,10 @@ struct dwc3 {
unsigneddis_split_quirk:1;
 
u16 imod_interval;
+
+   int max_cfg_eps;
+   int last_fifo_depth;
+   int num_ep_resized;
 };
 
 #define INCRX_BURST_MODE 0
@@ -1471,6 +1476,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned 
int cmd,
struct dwc3_gadget_ep_cmd_params *params);
 int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned int cmd,
u32 param);
+void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc);
 #else
 static inline int dwc3_gadget_init(struct dwc3 *dwc)
 { return 0; }
@@ -1490,6 +1496,8 @@ static inline int dwc3_send_gadget_ep_cmd(struct dwc3_ep 
*dep, unsigned int cmd,
 static inline int dwc3_send_gadget_generic_command(struct dwc3 *dwc,
int cmd, u32 param)
 { return 0; }
+static inline void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
+{ }
 #endif
 
 #if IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 8b668ef..4f216bd 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -616,6 +616,8 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
return -EINVAL;
 
case USB_STATE_ADDRESS:
+   dwc3_gadget_clear_tx_fifos(dwc);
+
ret = dwc3_ep0_delegate_req(dwc, ctrl);
/* if the cfg matches and the cfg is non zero */
if (cfg && (!ret || (ret == USB_GADGET_DELAYED_STATUS))) {
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 86f257f..26f9d64 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -615,6 +615,161 @@ static int dwc3_gadget_set_ep_config(struct dwc3_ep *dep, 
unsigned int action)
 static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force,
bool interrupt);
 
+static int dwc3_gadget_calc_tx_fifo_size(struct dwc3 *dwc, int mult)
+{
+   int max_packet = 1024;
+   int fifo_size;
+   int mdwidth;
+
+   mdwidth = DWC3_MDWIDTH(dwc->hwparams.hwparams0);
+   /* MDWIDTH is represented in bits, we need it in bytes */
+   mdwidth >>= 3;
+
+   fifo_size = mult * ((max_packet + mdwidth) / mdwidth) + 1;
+   return fifo_size;
+}
+
+void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
+{
+   struct dwc3_ep *dep;
+   int fifo_depth;
+   int size;
+   int num;
+
+   if (!dwc->needs_fifo_resize)
+   return;
+
+   /* Read ep0IN related TXFIFO size */
+   dep = dwc->eps[1];
+   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(0));
+   if (DWC3_IP_I

[PATCH v6 4/4] arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic

[Wesley Cheng]

Enable the flexible TX FIFO resize logic on SM8150.  Using a larger TX FIFO
SZ can help account for situations when system latency is greater than the
USB bus transmission latency.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi 
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 5270bda..c7706f4 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -1569,6 +1569,7 @@
iommus = <_smmu 0x140 0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+   tx-fifo-resize;
phys = <_1_hsphy>, <_1_ssphy>;
phy-names = "usb2-phy", "usb3-phy";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: usb: dwc3: gadget: skip pullup and set_speed after suspend

[Wesley Cheng]

On 1/21/2021 12:13 AM, Jung Daehwan wrote:
> On Wed, Jan 20, 2021 at 11:44:05PM -0800, Wesley Cheng wrote:
>>
>>
>> On 1/20/2021 10:49 PM, Jung Daehwan wrote:
>>> Hi,
>>>
>>> On Thu, Jan 21, 2021 at 01:00:32AM +, Thinh Nguyen wrote:
>>>> Hi,
>>>>
>>>> Daehwan Jung wrote:
>>>>> Sometimes dwc3_gadget_pullup and dwc3_gadget_set_speed are called after
>>>>> entering suspend. That's why it needs to check whether suspend
>>>>>
>>>>> 1. dwc3 sends disconnect uevent and turn off. (suspend)
>>>>> 2. Platform side causes pullup or set_speed(e.g., adbd closes ffs node)
>>>>> 3. It causes unexpected behavior like ITMON error.
>>>>>
>>>>> Signed-off-by: Daehwan Jung 
>>>>> ---
>>>>>  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 ee44321..d7d4202 100644
>>>>> --- a/drivers/usb/dwc3/gadget.c
>>>>> +++ b/drivers/usb/dwc3/gadget.c
>>>>> @@ -2093,6 +2093,9 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
>>>>> int is_on)
>>>>>   unsigned long   flags;
>>>>>   int ret;
>>>>>  
>>>>> + if (pm_runtime_suspended(dwc->dev))
>>>>> + return 0;
>>>>> +
>>>>>   is_on = !!is_on;
>>>>>  
>>>>>   /*
>>>>> @@ -2403,6 +2406,9 @@ static void dwc3_gadget_set_speed(struct usb_gadget 
>>>>> *g,
>>>>>   unsigned long   flags;
>>>>>   u32 reg;
>>>>>  
>>>>> + if (pm_runtime_suspended(dwc->dev))
>>>>> + return;
>>>>> +
>>>>>   spin_lock_irqsave(>lock, flags);
>>>>>   reg = dwc3_readl(dwc->regs, DWC3_DCFG);
>>>>>   reg &= ~(DWC3_DCFG_SPEED_MASK);
>>>>
>>>> This is already addressed in Wesley Cheng's patches. Can you try the
>>>> latest changes of DWC3 in Greg's usb-next branch?
>>>>
>>>> Thanks,
>>>> Thinh
>>>
>>> I checked Wesly Cheng's pathces but it's not same.
>>> What I want to do for this patch is to avoid pullup from platform side.
>>> (android in my case)
>>>
>>> It's possible that platform side tries to pullup by UDC_Store after usb is 
>>> already disconnected.
>>> It can finally run controller and enable irq.
>>>
>>> I think we have to avoid it and other possible things related to platform 
>>> side.
>>>
>>>
>>
>> Hi Daehwan,
>>
>> I think what you're trying to do is to avoid the unnecessary runtime
>> resume if the cable is disconnected and userspace attempts to
>> bind/unbind the UDC.
>>
>> I'm not exactly sure what patches you've pulled in, but assuming you
>> didn't pull in any of the recent suspend changes:
>>
>> usb: dwc3: gadget: Allow runtime suspend if UDC unbinded
>> usb: dwc3: gadget: Preserve UDC max speed setting
>>
>> Please consider the following scenario:
>> 1.  USB connected
>> 2.  UDC unbinded
>> 3.  DWC3 will continue to stay in runtime active, since dwc->connected =
>> true
>>
>> In this scenario, we should allow the DWC3 to enter runtime suspend,
>> since runstop has been disabled.
>>
>> If you have pulled in the above changes, and adding your changes on top
>> of it, then consider the following:
>> 1.  USB connected
>> 2.  UDC unbinded
>> 3.  DWC enters runtime suspend (due to the above changes)
>> 4.  UDC binded
>>
>> The check for pm_runtime_suspended() will block step#4 from re-enabling
>> the runstop bit even if the USB cable is connected.
>>
>> Thanks
>> Wesley Cheng
>>
>> -- 
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
> 
> Hi Wesley
> 
> The check for runtime_suspended() will block re-enabling the runstop bit as
> you said after pulling your patches in.
> 
> UDC is contolled by userspace and it's possible UDC can be binded
> unexpectedly. That's why I think it needs to handle it even if the
> problem is from userspace.
> 
> Below is an example in my environment.
> 
> 1. USB disconnected
> 2. UDC unbind

Re: [Emc-users] Rpi Pico

[Sven Wesley]

Den tors 21 jan. 2021 kl 17:51 skrev John Dammeyer :

> No CAN bus port.  No USB port.
>
> I guess it depends on how deep one wants to go into C programming as to
> what you might choose for independently controlled things like a tool
> changer.  I have PIC32 development boards and processors that support
> quadrature encoders.  Same dsPIC series with quadrature and CAN bus.
>
> The latest interesting and although a lot more money is:
> https://www.ti.com/tool/LAUNCHXL-F28379D
>
> With dual processors and a lot of other pretty cool features this could be
> made into a wicked pendant.
>
> John Dammeyer
>

You load the code over USB. The Pico doc has code examples for REPL over
USB, UART, I2C and SPI.
*3.2. UART*
*USB  serial  is  available  from  MicroPython,  but  the  REPL  is  also
 available  over  UART0  by  default.*
Isn't that USB communication?

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

[Mpi-forum] Registration for February 2021 Meeting

[Wesley Bland via mpi-forum]

Hi all,

Registration for the February 2021 Final Ratification Meeting is now open.
Please do so at this link:

https://forms.gle/ACFkW6oGy1bgT7pD9

I'll be updating the attendance list on the website periodically, but not
in real time. So if you'd like to check whether you've registered, the best
way to do so is by looking for your "receipt" in your email.

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

[Emc-users] Rpi Pico

[Sven Wesley]

For you people out there who use an Arduino or RPi to communicate with
parts of the machine (tool changers, doors etc). Here's a cute and really
low priced alternative.
https://www.raspberrypi.org/products/raspberry-pi-pico/

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

Re: usb: dwc3: gadget: skip pullup and set_speed after suspend

[Wesley Cheng]

On 1/20/2021 10:49 PM, Jung Daehwan wrote:
> Hi,
> 
> On Thu, Jan 21, 2021 at 01:00:32AM +, Thinh Nguyen wrote:
>> Hi,
>>
>> Daehwan Jung wrote:
>>> Sometimes dwc3_gadget_pullup and dwc3_gadget_set_speed are called after
>>> entering suspend. That's why it needs to check whether suspend
>>>
>>> 1. dwc3 sends disconnect uevent and turn off. (suspend)
>>> 2. Platform side causes pullup or set_speed(e.g., adbd closes ffs node)
>>> 3. It causes unexpected behavior like ITMON error.
>>>
>>> Signed-off-by: Daehwan Jung 
>>> ---
>>>  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 ee44321..d7d4202 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -2093,6 +2093,9 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
>>> int is_on)
>>> unsigned long   flags;
>>> int ret;
>>>  
>>> +   if (pm_runtime_suspended(dwc->dev))
>>> +   return 0;
>>> +
>>> is_on = !!is_on;
>>>  
>>> /*
>>> @@ -2403,6 +2406,9 @@ static void dwc3_gadget_set_speed(struct usb_gadget 
>>> *g,
>>> unsigned long   flags;
>>> u32 reg;
>>>  
>>> +   if (pm_runtime_suspended(dwc->dev))
>>> +   return;
>>> +
>>> spin_lock_irqsave(>lock, flags);
>>> reg = dwc3_readl(dwc->regs, DWC3_DCFG);
>>> reg &= ~(DWC3_DCFG_SPEED_MASK);
>>
>> This is already addressed in Wesley Cheng's patches. Can you try the
>> latest changes of DWC3 in Greg's usb-next branch?
>>
>> Thanks,
>> Thinh
> 
> I checked Wesly Cheng's pathces but it's not same.
> What I want to do for this patch is to avoid pullup from platform side.
> (android in my case)
> 
> It's possible that platform side tries to pullup by UDC_Store after usb is 
> already disconnected.
> It can finally run controller and enable irq.
> 
> I think we have to avoid it and other possible things related to platform 
> side.
> 
> 

Hi Daehwan,

I think what you're trying to do is to avoid the unnecessary runtime
resume if the cable is disconnected and userspace attempts to
bind/unbind the UDC.

I'm not exactly sure what patches you've pulled in, but assuming you
didn't pull in any of the recent suspend changes:

usb: dwc3: gadget: Allow runtime suspend if UDC unbinded
usb: dwc3: gadget: Preserve UDC max speed setting

Please consider the following scenario:
1.  USB connected
2.  UDC unbinded
3.  DWC3 will continue to stay in runtime active, since dwc->connected =
true

In this scenario, we should allow the DWC3 to enter runtime suspend,
since runstop has been disabled.

If you have pulled in the above changes, and adding your changes on top
of it, then consider the following:
1.  USB connected
2.  UDC unbinded
3.  DWC enters runtime suspend (due to the above changes)
4.  UDC binded

The check for pm_runtime_suspended() will block step#4 from re-enabling
the runstop bit even if the USB cable is connected.

Thanks
Wesley Cheng

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

Re: Getting column names/types from select query?

[Wesley Aptekar-Cassels]

> Where do you need this information?

I'm writing some code that takes a given query, and generates type-safe 
bindings for it, so people can write SQL queries and get structs (or vectors of 
structs) out the other end. So I'm pretty flexible about where I get it, given 
that it'll be part of my build/codegen process. I hadn't seen libpq yet, I'll 
look into that — thanks!

Getting column names/types from select query?

[Wesley Aptekar-Cassels]

Hi all,

I am interested in figuring out how to get the names and types of the columns 
from an arbitrary query. Essentially, I want to be able to take a query like:

CREATE TABLE foo(
bar bigserial,
baz varchar(256)
);

SELECT * FROM foo WHERE bar = 42;

and figure out programmatically that the select will return a column "bar" of 
type bigserial, and a column "foo" of type varchar(256). I would like this to 
work for more complex queries as well (joins, CTEs, etc).

I've found https://wiki.postgresql.org/wiki/Query_Parsing, which talks about 
related ways to hook into postgres, but that seems to only talk about the parse 
tree — a lot more detail and processing seems to be required in order to figure 
out the output types. It seems like there should be somewhere I can hook into 
in postgres that will get me this information, but I have no familiarity with 
the codebase, so I don't know the best way to get this.

How would you recommend that I approach this? I'm comfortable patching postgres 
if needed, although if there's a solution that doesn't require that, I'd prefer 
that.

Thanks,

:w

[Interest] Qt Desktop push notifications, can't get to NSApplication?

[Wesley Krasko]

Hi. So we are trying to add push notifications to an existing Qt Desktop
application. Mac OS is first priority.

However, I can't figure out how to get to NSApplication to register to APN.
I looked here, although it's for iOS and Android:

https://github.com/gympulsr/qt-pushnotifications

Simple code so converted to MacOS, mostly changed the mm file:

#include 

#include "pushnotification.h"


@interface QMacOSApplicationDeligate

@end

//add a category to AppDelegate

@interface QMacOSApplicationDeligate (QPushNotificationDelegate)

@end



@implementation QMacOSApplicationDeligate (QPushNotificationDelegate)

- (BOOL)application:(NSApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {



//-- Set Notification

[application registerForRemoteNotifications];

return YES;

}



- (void)application:(NSApplication *)application
didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken
{

NSLog(@"Did Register for Remote Notifications with Device Token
(%@)", deviceToken);



//const unsigned *tokenBytes = (const unsigned*)[deviceToken bytes];

//NSString *tokenStr = [NSString
stringWithFormat:@"%08x%08x%08x%08x%08x%08x%08x%08x",

//  ntohl(tokenBytes[0]),
ntohl(tokenBytes[1]), ntohl(tokenBytes[2]),

//  ntohl(tokenBytes[3]),
ntohl(tokenBytes[4]), ntohl(tokenBytes[5]),

//  ntohl(tokenBytes[6]), ntohl(tokenBytes[7])];

//
PushNotificationRegistrationTokenHandler::instance()->setAPNSRegistrationToken(QString::fromNSString(tokenStr));

}



- (void)application:(NSApplication *)application
didFailToRegisterForRemoteNotificationsWithError:(NSError *)error {

NSLog(@"Did Fail to Register for Remote Notifications");

NSLog(@"%@, %@", error, error.localizedDescription);



}

@end

But, I'm getting exactly this issue, looks like they were trying to do
almost the same thing. I can't figure out how I can do this, any
suggestions?
https://interest.qt-project.narkive.com/6v9o61We/objective-c-category-for-qcocoaapplicationdelegate-undefined-symbols


-- 
Wes Krasko
www.worldwidewes.com
www.kraskofamily.com
"Stay away from negative people. They have a problem for every solution."
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Mpi-forum] Reading Announcement for #283

[Wesley Bland via mpi-forum]

Hi all,

I'd like to announce a short MPI 4.1 reading (time permitting) for the
upcoming meeting. This issue has been read before and passed a first vote,
but there were some good points raised at the last meeting that I think
were significant enough to merit a re-reading and starting the process
over. The issue and pull request are:

Add MPI_Delete_error_class, MPI_Delete_error_code, MPI_Delete_error_string:
https://github.com/mpi-forum/mpi-issues/issues/283
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 v2 2/2] resource: Make it possible to reserve memory on 64bit platform

[Wesley Zhao]

For now "reserve=" is limitied to 32bit,not available on 64bit
platform,so we change the get_option() to get_option_ull(added in
patch: commit 4b6bfe96265e ("lib/cmdline: add new function
get_option_ull()"))

Signed-off-by: Wesley Zhao 
---
 kernel/resource.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 833394f9c608..ee2a0e5d196f 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1567,13 +1567,13 @@ static int __init reserve_setup(char *str)
static struct resource reserve[MAXRESERVE];
 
for (;;) {
-   unsigned int io_start, io_num;
+   unsigned long long io_start, io_num;
int x = reserved;
struct resource *parent;
 
-   if (get_option(, _start) != 2)
+   if (get_option_ull(, _start) != 2)
break;
-   if (get_option(, _num) == 0)
+   if (get_option_ull(, _num) == 0)
break;
if (x < MAXRESERVE) {
struct resource *res = reserve + x;
-- 
2.7.4

[PATCH v2 0/2] Make it possible to reserve memory on 64bit platform

[Wesley Zhao]

I was trying to reserve some memory to save logs incase that Android panic or 
hang and then
I can read the logs from QNX side from the memory reserved before on the 
Qualcomm 8155 hypervisor platform,
and I find the "reserve=" parameter only support 32bit,so I made some change 
and send these patches.

testcase:
I test on the qemu with some cmdline like[qemu-system-x86_64 -kernel 
linux-next/arch/x86_64/boot/bzImage
-hda ubuntu-system.ext4 -append "root=/dev/sda init=/bin/bash 
console=ttyS0 reserve=0x18000,0x123456"
-nographic] and check the /proc/iomem with 18000-180123455 : 
reserved.
And some other tests with the get_option with the parameter(-12345678) 
and so on

Wesley Zhao (2):
  lib/cmdline: add new function get_option_ull()
  resource: Make it possible to reserve memory on 64bit platform

 include/linux/kernel.h |  2 ++
 kernel/resource.c  |  6 ++--
 lib/cmdline.c  | 94 ++
 3 files changed, 85 insertions(+), 17 deletions(-)

-- 
2.7.4

[PATCH v2 1/2] lib/cmdline: add new function get_option_ull()

[Wesley Zhao]

In the future we would pass the unsigned long long parameter
like(0x123456781234) in cmdline on the 64bit platform, so add a new
option parse function get_option_ull()

Signed-off-by: Wesley Zhao 
---
 include/linux/kernel.h |  2 ++
 lib/cmdline.c  | 94 ++
 2 files changed, 82 insertions(+), 14 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f7902d8c1048..eb1f0b14a0c5 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -348,6 +348,8 @@ extern __scanf(2, 0)
 int vsscanf(const char *, const char *, va_list);
 
 extern int get_option(char **str, int *pint);
+extern int get_option_ll(char **str, long long *pll);
+extern int get_option_ull(char **str, unsigned long long *pull);
 extern char *get_options(const char *str, int nints, int *ints);
 extern unsigned long long memparse(const char *ptr, char **retptr);
 extern bool parse_option_str(const char *str, const char *option);
diff --git a/lib/cmdline.c b/lib/cmdline.c
index b390dd03363b..d32b585d287d 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -31,6 +31,81 @@ static int get_range(char **str, int *pint, int n)
*pint++ = x;
return inc_counter;
 }
+/**
+ * get_option_ull - Parse unsigned long long from an option string
+ * @str: option string
+ * @pull: (output) unsigned long long value parsed from @str
+ *
+ * Read an unsigned long long from an option string; if available accept a 
subsequent
+ * comma as well.
+ *
+ * Return values:
+ * 0 - no ull in string
+ * 1 - ull found, no subsequent comma
+ * 2 - ull found including a subsequent comma
+ * 3 - hyphen found to denote a range
+ */
+
+int get_option_ull(char **str, unsigned long long *pull)
+{
+   char *cur = *str;
+   unsigned long long value;
+
+   if (!cur || !(*cur))
+   return 0;
+   value = simple_strtoull(cur, str, 0);
+   if (pull)
+   *pull = value;
+   if (cur == *str)
+   return 0;
+   if (**str == ',') {
+   (*str)++;
+   return 2;
+   }
+   if (**str == '-')
+   return 3;
+
+   return 1;
+}
+EXPORT_SYMBOL(get_option_ull);
+
+/**
+ * get_option_ll - Parse long long from an option string
+ * @str: option string
+ * @pll: (output) long long value parsed from @str
+ *
+ * Read an long long from an option string; if available accept a 
subsequent
+ * comma as well.
+ *
+ * Return values:
+ * 0 - no ll in string
+ * 1 - ll found, no subsequent comma
+ * 2 - ll found including a subsequent comma
+ * 3 - hyphen found to denote a range
+ */
+
+int get_option_ll(char **str, long long *pll)
+{
+   char *cur = *str;
+   unsigned long long value;
+   int ret;
+
+   if (!cur || !(*cur))
+   return 0;
+   if (*cur == '-') {
+   cur = cur + 1;
+   ret = get_option_ull((char **), );
+   if (pll)
+   *pll = -value;
+   } else {
+   ret = get_option_ull(str, );
+   if (pll)
+   *pll = value;
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL(get_option_ll);
 
 /**
  * get_option - Parse integer from an option string
@@ -56,26 +131,17 @@ static int get_range(char **str, int *pint, int n)
 int get_option(char **str, int *pint)
 {
char *cur = *str;
-   int value;
+   long long value;
+   int ret;
 
if (!cur || !(*cur))
return 0;
-   if (*cur == '-')
-   value = -simple_strtoull(++cur, str, 0);
-   else
-   value = simple_strtoull(cur, str, 0);
+   ret = get_option_ll(str, );
+
if (pint)
*pint = value;
-   if (cur == *str)
-   return 0;
-   if (**str == ',') {
-   (*str)++;
-   return 2;
-   }
-   if (**str == '-')
-   return 3;
 
-   return 1;
+   return ret;
 }
 EXPORT_SYMBOL(get_option);
 
-- 
2.7.4

Re: Looking for feedback on the Ignite 3.0.0 Alpha

[Wesley Peng]

When will the stable version of 3.0 get released? thanks.

Valentin Kulichenko wrote:
I'm excited to announce that the first alpha build of the Ignite 3 is 
out and available for download!


Ignite 3 is the new project that was initiated by the Ignite community 
last year. Please refer to this page if you want to learn more: 
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0 



The just-released alpha build is a sneak peek into the future of Ignite. 
It doesn't represent a fully-functional product (no discovery, caches, 
compute, etc.), but demonstrates major mechanics of how you will 
interact with Ignite going forward.

[PATCH 2/2] resource: Make it possible to reserve memory on 64bit platform

[Wesley Zhao]

From: "Wesley.Zhao" 

For now "reserve=" is limitied to 32bit,not available on 64bit
platform,so we change the get_option() to get_option_ull(added in
patch: commit 4b6bfe96265e ("lib/cmdline: add new function
get_option_ull()"))

Signed-off-by: Wesley.Zhao 
---
 kernel/resource.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 833394f..ee2a0e5 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1567,13 +1567,13 @@ static int __init reserve_setup(char *str)
static struct resource reserve[MAXRESERVE];
 
for (;;) {
-   unsigned int io_start, io_num;
+   unsigned long long io_start, io_num;
int x = reserved;
struct resource *parent;
 
-   if (get_option(, _start) != 2)
+   if (get_option_ull(, _start) != 2)
break;
-   if (get_option(, _num) == 0)
+   if (get_option_ull(, _num) == 0)
break;
if (x < MAXRESERVE) {
struct resource *res = reserve + x;
-- 
2.7.4

[PATCH 1/2] lib/cmdline: add new function get_option_ull()

[Wesley Zhao]

From: "Wesley.Zhao" 

In the future we would pass the unsigned long long parameter
like(0x123456781234) in cmdline on the 64bit platform, so add a new
option parse function get_option_ull()

Signed-off-by: Wesley.Zhao 
---
 include/linux/kernel.h |  1 +
 lib/cmdline.c  | 35 +++
 2 files changed, 36 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f7902d8..5568133 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -348,6 +348,7 @@ extern __scanf(2, 0)
 int vsscanf(const char *, const char *, va_list);
 
 extern int get_option(char **str, int *pint);
+extern int get_option_ull(char **str, unsigned long long *pull);
 extern char *get_options(const char *str, int nints, int *ints);
 extern unsigned long long memparse(const char *ptr, char **retptr);
 extern bool parse_option_str(const char *str, const char *option);
diff --git a/lib/cmdline.c b/lib/cmdline.c
index b390dd0..2d089a2 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -80,6 +80,41 @@ int get_option(char **str, int *pint)
 EXPORT_SYMBOL(get_option);
 
 /**
+ * get_option_ull - Parse unsigned long long from an option string
+ * @str: option string
+ * @pull: (output) unsigned long long value parsed from @str
+ *
+ * Read an unsigned long long from an option string; if available accept a 
subsequent
+ * comma as well.
+ *
+ * Return values:
+ * 0 - no ull in string
+ * 1 - ull found, no subsequent comma
+ * 2 - ull found including a subsequent comma
+ * 3 - hyphen found to denote a range
+ */
+
+int get_option_ull(char **str, unsigned long long *pull)
+{
+   char *cur = *str;
+
+   if (!cur || !(*cur))
+   return 0;
+   *pull = simple_strtoull(cur, str, 0);
+   if (cur == *str)
+   return 0;
+   if (**str == ',') {
+   (*str)++;
+   return 2;
+   }
+   if (**str == '-')
+   return 3;
+
+   return 1;
+}
+EXPORT_SYMBOL(get_option_ull);
+
+/**
  * get_options - Parse a string into a list of integers
  * @str: String to be parsed
  * @nints: size of integer array
-- 
2.7.4

Re: [Mpi-forum] Big Fortran hole in MPI-4.0 Embiggening

[Wesley Bland via mpi-forum]

I agree with Jeff that this is a non-issue. Bill’s assertion that adding 
Fortran support for large count once you have C support has been true in MPICH 
development at least and no vender would drop anything just to put MPI 4.0 
compatibility on a marketing slide. They’d just put it on the slide anyway. 
Every implementation out there has some sort of exception, intentional or 
otherwise, that makes them technically non-compliant. In the end, their users 
determine 1) whether they care enough to request the feature and 2) whether 
they care enough to switch to a competing library.

I think the best way forward is to do something like what had been proposed 
when the embiggening/pythonization started and separate bindings from 
specification and just say that an MPI implementation has MPI 4.0 C bindings 
and MPI 3.1 F08 bindings and MPI 5.0 Python bindings. That means each binding 
can be updated in whatever way makes sense for them. For 4.0, I don’t think 
this is an issue that needs to be resolved. Us telling the implementations what 
they have to do will have essentially no impact anyway.

Thanks,
Wes

> On Jan 11, 2021, at 6:26 AM, Rolf Rabenseifner via mpi-forum 
>  wrote:
> 
> Dear Jeff and all,
> 
>> I think their users would be very unhappy.
> 
> Yes, users can be unhappy and compute centers may definitely recommend 
> an other MPI library - at least for any software development.
> 
> I want to remember that MPI-3.1 requires for the mpi module:
> 
> "Provide explicit interfaces according to the Fortran routine interface speci
> cations.
> This module therefore guarantees compile-time argument checking and allows 
> positional
> and keyword-based argument lists. If an implementation is paired with a
> compiler that either does not support TYPE(*), DIMENSION(..) from TS 29113, or
> is otherwise unable to ignore the types of choice buffers, then the 
> implementation must
> provide explicit interfaces only for MPI routines with no choice buer 
> arguments. See
> Section 17.1.6 for more details."
> 
> Although there are no more such compilers that do not provide one of the two 
> methods,
> there are more than 5 years after MPI-3.1 still MPI libraries that do not
> provide keyword-based argument lists with the mpi module.
> And those libraries provide such support for the mpi_f08 module.
> This means, they prove that they are not MPI-3.1 compliant :-)
> 
> 
> Sometimes implementors ignore the goals and the wording of the MPI standard. 
> 
> 
> And there is also no request that users want to have a less-quality
> mpi module definition.
> 
> Best regards
> Rolf
> 
> 
> - Original Message -
>> From: "Main MPI Forum mailing list" 
>> To: "Main MPI Forum mailing list" 
>> Cc: "Jeff Squyres" 
>> Sent: Sunday, January 10, 2021 5:09:55 PM
>> Subject: Re: [Mpi-forum] Big Fortran hole in MPI-4.0 Embiggening
> 
>> I can't imagine a vendor would:
>> 
>> - support mpi_f08
>> - then stop supporting mpi_f08 just so that they can get an "MPI-4.0" release
>> out
>> - then support mpi_f08 again
>> 
>> I think their users would be very unhappy.
>> 
>> 
>> 
>> 
>> 
>> On Jan 10, 2021, at 10:55 AM, William Gropp via mpi-forum < [
>> mailto:mpi-forum@lists.mpi-forum.org  
>> | mpi-forum@lists.mpi-forum.org  ] > 
>> wrote:
>> 
>> I agree with Dan that this is a big change from the RCM. Further, the 
>> approach
>> in MPI has always been to encourage the users to make it clear to the vendors
>> what is acceptable in implementations, especially implementation schedules.
>> Nothing in the standard prohibits implementors from continuing to provide MPI
>> 3.x implementations while they work to provide a full MPI 4.0 implementation.
>> The MPI forum has no enforcement power on the implementors, and I believe 
>> this
>> text is unnecessary and will not provide the guarantee that Rolf wants.
>> Further, frankly once the C embiggened interface is implemented, creating the
>> mpi_f08 version is relatively straightforward.
>> 
>> Bill
>> 
>> William Gropp
>> Director, NCSA
>> Thomas M. Siebel Chair in Computer Science
>> University of Illinois Urbana-Champaign
>> IEEE-CS President-Elect
>> 
>> 
>> 
>> 
>> 
>> 
>> On Jan 10, 2021, at 7:44 AM, HOLMES Daniel via mpi-forum < [
>> mailto:mpi-forum@lists.mpi-forum.org  
>> | mpi-forum@lists.mpi-forum.org  ] > 
>> wrote:
>> 
>> Hi Rolf,
>> 
>> This is a (somewhat contrived, arguably) reason for taking another tiny step
>> towards removing the “mpif.h” method of Fortran support and pushing users and
>> implementations towards preferring the Fortran 2008 interface, which is a
>> direction of travel that I fully support.
>> 
>> I think this might be seen as quite a big change for implementers, 
>> especially if
>> it were to occur between the RCM and FRM.
>> 
>> Cheers,
>> Dan.
>> —
>> Dr Daniel Holmes PhD
>> Architect (HPC Research)

Re: Machine Learning

[Wesley Shields]

I'm far from an expert but "these samples cluster around this rule or this 
subset of rules" is far from machine learning. There's no learning there at all.

We have used YARA to extract out features from various documents (specifically 
things like RTF where you can easily count the number of different tags, their 
relative position, etc) and then used those features to train a ML model. It 
can be done, and can work well but YARA may not be the best tool in most cases.

Just labeling a cluster based upon a set of rules that match is not machine 
learning. That is just labeling.

-- WXS

> On Jan 11, 2021, at 4:51 AM, raghvendra mishra  
> wrote:
> 
> Hi Arun,
> What about using Yara rule pattern(s) as a feature, think about it. In this 
> way you can have clusters based upon family etc.
> 
> Cheers,
> --Raghvendra Mishra
> Principal Threat Researcher
> SonicWall Inc.
> Cell:- +91-8867404241
> 
> 
> On Thu, Jan 7, 2021 at 11:28 PM arun rawat  > wrote:
> Hi Everyone,
> 
> I am a college student working on a malware detection project.
> 
> Someone told me that "Yara rules can also be used to convert a big data set 
> in the form of clusters in machine learning " and it has a different use at 
> different platforms.
> 
> I am a bit confused, Is it true or not. 
> 
> Your advice can help a student to complete his Project.
> 
> Thank you in advance.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/53e7b170-00e0-4f6d-ab1a-72c3920baa3an%40googlegroups.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/CACAQ8EBighB6m%2Bk_EYabwqin5fVJRgHb83L3xicZ5XXAY8eHYg%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/BF164FD0-9374-4F7F-B7E6-B2983FB5094E%40gmail.com.

Re: How do you Default to Huge VT Fonts?

['Wesley Gibbs' via tmux-users]

Thank you for the quick response, this makes total sense, will look at how to 
make this work for a terminal default.


> On Jan 11, 2021, at 8:57 AM, Nicholas Marriott  
> wrote:
> 
> 
> Font size is a property of your terminal not of tmux.
> 
>> On Mon, 11 Jan 2021 at 13:56, 'Wesley Gibbs' via tmux-users 
>>  wrote:
>> I use the latest stable version of Tmux on a daily basis.
>> 
>> Every day after opening Tmux, the first action I take is hitting Ctrl-Right 
>> clicking, the selecting huge for the VT fonts value.
>> 
>> Is there a setting that I can put in .tmux.conf to avoid this action every 
>> time I use Tmux?
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "tmux-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to tmux-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit 
>> https://groups.google.com/d/msgid/tmux-users/1A4ADF34-EB89-46BE-B31F-99795CF87A04%40me.com.

-- 
You received this message because you are subscribed to the Google Groups 
"tmux-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tmux-users+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/tmux-users/6E9E6CA5-8040-4B99-8237-E7571353F84F%40me.com.

How do you Default to Huge VT Fonts?

['Wesley Gibbs' via tmux-users]

I use the latest stable version of Tmux on a daily basis.

Every day after opening Tmux, the first action I take is hitting Ctrl-Right 
clicking, the selecting huge for the VT fonts value.

Is there a setting that I can put in .tmux.conf to avoid this action every time 
I use Tmux?

-- 
You received this message because you are subscribed to the Google Groups 
"tmux-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tmux-users+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/tmux-users/1A4ADF34-EB89-46BE-B31F-99795CF87A04%40me.com.

Re: [Emc-users] GUI Feature Request

[Sven Wesley]

Den tis 5 jan. 2021 kl 15:36 skrev Todd Zuercher :

> I've noticed what appears to be a lot of new development of new GUIs for
> Linuxcnc lately.  Here is an idea that I would love to see implemented in a
> new GUI, but I do not have the programming skills to implement it.  For our
> production machines it would be nice for the supervisors to be able to set
> up a que of g-code files for shifts to run.  The que would be a list of
> g-code files, and their location paths (possibly a network location), the
> number of repeats to run, and possibly a material to be used description.
> Then the machine operators would simply unload/load the machine, and press
> start, once the required number of runs is completed the gui would
> automatically load the next g-code file in the que and prompt the user what
> material to load for the next run.  How hard might something like this be
> to implement?
>
>
> Todd Zuercher
>
>
In the workshop I was working in during the 90's we already used this
setup. All machines were fed with programs from a minix server that we used
as a file service at the CAM stations.
Spontaneusly I would say that if you have a File/HTTP server it should be
fairly easy to make a user space component that fetches the programs, i.e.
not so much GUI related really but you can get a tab or dialog listing
upcoming runs.

/Sven

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

Re: This is a test

[Wesley Peng]

Please don't send a test message to the public list which was read by
thousands of people. thanks.

On Fri, Jan 8, 2021 at 5:26 AM Craig Hatch  wrote:

> I have added you to the EMAIL  list, so when I have questions.
>
> Just learn for fun.
>
>
> Craig Hatch
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: graceful shutdown for C++ applications

[Wesley Peng]

Issuing a command like "kill process_id"  doesn't work?

regards.

On Thu, Jan 7, 2021 at 4:14 PM rakshita04 
wrote:

> Hi Team,
>
> We are using apache-ignite for our applications running on 2 machines and
> connected over network.
> We are facing some issue where if kill is performed on running application,
> it somehow corrupts the node and then node never comes up and keep on
> rebooting.
> Is there a way to handle this shutdown gracefully? so that there is no data
> loss and node corruption.
>
> regards,
> Rakshita Chaudhary
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: [ANNOUNCE] New Pulsar Committer: LinLin

[Wesley Peng]

Congrats Linlin~

Regards.

On Wed, Jan 6, 2021 at 5:25 PM Jinfeng Huang  wrote:

> Congratulations to Linlin~
>
> Best Regards,
> Jennifer
>
>
> On Wed, Jan 6, 2021 at 3:30 PM Matthias Peng 
> wrote:
>
>> congratulations linlin!
>>
>> On Wed, Jan 6, 2021 at 3:05 PM PengHui Li  wrote:
>>
>>> The Apache Pulsar PMC recently extended committer karma to LinLin and he
>>> has accepted.
>>> LinLin has done a lot of contributions to Pulsar core features and bug
>>> fixes. It is great to have LinLin onboard as Pulsar committers.
>>>
>>> We are looking forward to more contributions from him.
>>>
>>> Congratulations and welcome onboard LinLin!
>>>
>>> -
>>>
>>> Penghui on behave of the Pulsar PMC
>>>
>>

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

[Wesley Cheng]

On 1/4/2021 7:45 AM, Greg KH wrote:
> On Tue, Dec 29, 2020 at 03:03:31PM -0800, Wesley Cheng wrote:
>> 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
>>
> 
> So this changes the existing userspace functionality?  What will break
> because of this now unexpected change?
> 
> thanks,
> 
> greg k-h
> 

Hi Greg,

Happy new years!  This wouldn't affect the userspace interaction with
configFS, as this is modifying the reset callback for the UDC core.  The
reset callback is only executed during usb_gadget_udc_reset(), which is
specifically run when vendor UDC drivers (i.e. DWC3 gadget) receive a
USB bus reset interrupt.  This is similar to the composite.c patch,
because for configFS based gadgets, they do not directly register the
USB composite ops and have their own routines.

Thanks
Wesley Cheng

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

Re: [Emc-users] Interesting GUI

[Sven Wesley]

Den lör 2 jan. 2021 22:11andy pugh  skrev:

> On Sat, 2 Jan 2021 at 20:17, Sven Wesley  wrote:
>
> > Going back to original post from Andy, Mazak has some pretty funky GUIs
> > nowadays too.
> >
> https://mazakfiles.blob.core.windows.net/web-site/image/403f2cf63ed244ebbd11b6e32a8d8051/PreviewG_image_1.png
>
> I think that looks a little _too_ funky :-)
>
> What I liked about the original one I posted was the very good
> integration of touch.
>

Yeah agree. Not sure I wanna buy a 20 ton machine with a Call of Duty UI...
I like the Datron style, it is very clean and utilises the entire screen in
a good way (no empty spots).

>

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

Re: [Emc-users] Interesting GUI

[Sven Wesley]

6 sep. 2020 kl 22:16 skrev Kurt Jacobson :

> Aaron Dargel has been working on some pretty neat conversation widgets for
> QtPyVCP based ProbeBasic GUI.
> So far his just don't basic things like hole circles and facing ops, but
> they have excellent sanity checking that makes them almost foolproof to
> use.
> There are some screenshots here:
> https://github.com/kcjengr/qtpyvcp/pull/49
>
>
Going back to original post from Andy, Mazak has some pretty funky GUIs
nowadays too.
https://mazakfiles.blob.core.windows.net/web-site/image/403f2cf63ed244ebbd11b6e32a8d8051/PreviewG_image_1.png

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