from:"Wesley"

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

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

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

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

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

Wesley Cheng (3):
  arm64: boot: dts: qcom: sm8150: Add nodes for PMIC based typec
detection
  phy: qcom-qmp: Register as a typec switch for orientation detection
  usb: dwc3: dwc3-qcom: Find USB connector and register role switch

 arch/arm64/boot/dts/qcom/sm8150-mtp.dts |  37 -
 drivers/phy/qualcomm/Kconfig|  11 +++
 drivers/phy/qualcomm/phy-qcom-qmp.c |  71 +++-
 drivers/usb/dwc3/dwc3-qcom.c| 103 +++-
 4 files changed, 216 insertions(+), 6 deletions(-)

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

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

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

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

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index e1e78e9824b1..fe1e8a4ab7d6 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "core.h"
 
@@ -71,6 +73,9 @@ struct dwc3_qcom {
struct notifier_block   vbus_nb;
struct notifier_block   host_nb;
 
+   struct usb_role_switch *role_sw;
+   struct usb_role_switch *dwc3_drd_sw;
+
const struct dwc3_acpi_pdata *acpi_pdata;
 
enum usb_dr_modemode;
@@ -190,6 +195,73 @@ static int dwc3_qcom_register_extcon(struct dwc3_qcom 
*qcom)
return 0;
 }
 
+static int dwc3_qcom_usb_role_switch_set(struct usb_role_switch *sw,
+enum usb_role role)
+{
+   struct dwc3_qcom *qcom = usb_role_switch_get_drvdata(sw);
+   struct fwnode_handle *child;
+   bool enable = false;
+
+   if (!qcom->dwc3_drd_sw) {
+   child = device_get_next_child_node(qcom->dev, NULL);
+   if (child) {
+   qcom->dwc3_drd_sw = 
usb_role_switch_find_by_fwnode(child);
+   fwnode_handle_put(child);
+   if (IS_ERR(qcom->dwc3_drd_sw)) {
+   qcom->dwc3_drd_sw = NULL;
+   return 0;
+   }
+   }
+   }
+
+   usb_role_switch_set_role(qcom->dwc3_drd_sw, role);
+
+   if (role == USB_ROLE_DEVICE)
+   enable = true;
+   else
+   enable = false;
+
+   qcom->mode = (role == USB_ROLE_HOST) ? USB_DR_MODE_HOST :
+  USB_DR_MODE_PERIPHERAL;
+   dwc3_qcom_vbus_overrride_enable(qcom, enable);
+   return 0;
+}
+
+static enum usb_role dwc3_qcom_usb_role_switch_get(struct usb_role_switch *sw)
+{
+   struct dwc3_qcom *qcom = usb_role_switch_get_drvdata(sw);
+   enum usb_role role;
+
+   switch (qcom->mode) {
+   case USB_DR_MODE_HOST:
+   role = USB_ROLE_HOST;
+   break;
+   case USB_DR_MODE_PERIPHERAL:
+   role = USB_ROLE_DEVICE;
+   break;
+   default:
+   role = USB_ROLE_DEVICE;
+   break;
+   }
+
+   return role;
+}
+
+static int dwc3_qcom_setup_role_switch(struct dwc3_qcom *qcom)
+{
+   struct usb_role_switch_desc dwc3_role_switch = {NULL};
+
+   dwc3_role_switch.fwnode = dev_fwnode(qcom->dev);
+   dwc3_role_switch.set = dwc3_qcom_usb_role_switch_set;
+   dwc3_role_switch.get = dwc3_qcom_usb_role_switch_get;
+   dwc3_role_switch.driver_data = qcom;
+   qcom->role_sw = usb_role_switch_register(qcom->dev, _role_switch);
+   if (IS_ERR(qcom->role_sw))
+   return PTR_ERR(qcom->role_sw);
+
+   return 0;
+}
+
 static void dwc3_qcom_disable_interrupts(struct dwc3_qcom *qcom)
 {
if (qcom->hs_phy_irq) {
@@ -540,6 +612,25 @@ static int dwc3_qcom_of_register_core(struct 
platform_device *pdev)
return 0;
 }
 
+static void *dwc3_qcom_find_usb_connector_match(struct device_connection *con,
+   int ep, void *data)
+{
+   if (!fwnode_property_match_string(con->fwnode, "compatible",
+ "gpio-usb-b-connector") ||
+   !fwnode_property_match_string(con->fwnode, "compatible",
+ "usb-c-connector"))
+   return con->fwnode;
+   return 0;
+}
+
+static bool dwc3_qcom_find_usb_connector(struct platform_device *pdev)
+{
+   struct fwnode_handle *fwnode = pdev->dev.fwnode;
+
+   return fwnode_connection_find_match(fwnode, "connector", NULL,
+   dwc3_qcom_find_usb_connector_match);
+}
+
 static int dwc3_qcom_probe(struct platform_device *pdev)
 {
struct device_node  *np = pdev->dev.of_node;
@@ -644,8 +735,13 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
if (qcom->mode == USB_DR_MODE_PERIPHERAL)
dwc3_qcom_vbus_overrride_enable(qcom, true);
 
-   /* register extcon to override sw_vbus on Vbus change later */
-   ret = dwc3_qcom_register_extcon(qcom);
+   if (dwc3_qcom_find_usb_connector(pdev)) {

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

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

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

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

[SOLVED] RE: [External] - Re: Issues getting Kerberos to work with realmd and Active Directory

2020-07-30 Thread Wesley Taylor

Thank you all for your responses. Fortunately for me, just running klist and 
picking the UPN form got me past this issue, but if I run into any issues in 
the future I will employ those other solutions. I appreciate the help!

-Wes

Public Content

-Original Message-
From: Simo Sorce 
Sent: Thursday, July 30, 2020 12:33 PM
To: Wesley Taylor ; kerberos@mit.edu
Subject: [External] - Re: Issues getting Kerberos to work with realmd and 
Active Directory

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Wesley,
when joining hosts to AD a computer account is created and a UPN and SPNs are 
set on it.
Unlike MIT kerberos in AD heavy use of aliases is employed so each host have a 
"host password/key" that is shared with all the aliases created.
Most notably there are the UPN, generally of the form computername$@REALM and 
the SPNs which are a large number of service/fqdn@REALM principal names.

The important part here is that while you can get tickets for any of those 
names (the KDC has many canonicalization rules that will also match in a 
case-insensitive way) when you ask for a TGT (the kinit
operation) AD normally will accept a request only if the UPN form is used as 
the client principal and will refuse other forms (even though the key is the 
same).

realmd has an option to specify what to set the UPN to to change the default 
AD behavior. (See the --user-principal option in realm.8 manpage). You can use 
it to control what to use at join time, then you should be able to use exactly 
that name to kinit from the generated keytan.

HTH,
Simo.

On Thu, 2020-07-30 at 17:00 +0000, Wesley Taylor wrote:
> Hi All,
>
> I am trying to get HTCondor with Kerberos authentication (
> https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fhtc
> ondor.readthedocs.io%2Fen%2Fstable%2Fadmin-manual%2Fsecurity.html%3Fhi
> ghlight%3DKerberos%23kerberos-authenticationdata=02%7C01%7C%7Cbb5
> bd43850e34b17771508d834b70953%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7
> C0%7C637317308723651795sdata=uYxqJbuTqP8JbYm8Qx4oZjyGKhI1hTVWkAYH
> IKooivI%3Dreserved=0
> ) to work on some linux machines I have which I joined to Windows
> Active Directory with realmd. HTCondor tries to authenticate with the
> machine principal, but I am having a hard time figuring out what that
> is. When I run 'klist -k' I see a bunch of entries from
> /etc/krb5.keytab along the lines of host/fqdn@REALM. However, when I
> run 'kinit -k' I get "kinit: Client $(hostname) not found in Kerberos
> database".
>
> I then interrogated the realm with adcli, using 'adcli testjoin -- 
> verbose' and it outputs the computer account name as
> HOST/HOSTNAME@REALM. When I run 'kinit -k HOST/HOSTNAME@REALM' I get
> back the error "kinit: Keytab contains no suitible keys for
> HOST/HOSTNAME@REALM".
>
> I am confused because when I run 'adcli update --verbose' it says it
> updated the keytab at /etc/krb5.keytab and outputs the same account
> name (which I am assuming is the principal for the computer) as adcli
> testjoin. I am really scratching my head about this, what am I doing
> wrong here?
>
> Thanks,
> Wes
>
>
> Public Content
> 
> The information contained in this e-mail and any attachments from
> Numerica Corporation may contain confidential and/or proprietary
> information, and is intended only for the named recipient to whom it
> was originally addressed. If you are not the intended recipient, any
> disclosure, distribution, or copying of this e-mail or its attachments
> is strictly prohibited. If you have received this e-mail in error,
> please notify the sender immediately by return e-mail and permanently
> delete the e-mail and any attachments.
>
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fmai
> lman.mit.edu%2Fmailman%2Flistinfo%2Fkerberosdata=02%7C01%7C%7Cbb5
> bd43850e34b17771508d834b70953%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7
> C0%7C637317308723661788sdata=pJu5e9HEezwdpbsZUWEVtaC0chLiI0%2BiMV
> MV2UeuO5c%3Dreserved=0
>

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

smime.p7s
Description: S/MIME cryptographic signature

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Issues getting Kerberos to work with realmd and Active Directory

2020-07-30 Thread Wesley Taylor

Hi All,

I am trying to get HTCondor with Kerberos authentication
(https://htcondor.readthedocs.io/en/stable/admin-manual/security.html?highlight=Kerberos#kerberos-authentication)
to work on some linux machines I have which I joined to Windows Active
Directory with realmd. HTCondor tries to authenticate with the machine
principal, but I am having a hard time figuring out what that is. When I run
'klist -k' I see a bunch of entries from /etc/krb5.keytab along the lines of
host/fqdn@REALM. However, when I run 'kinit -k' I get "kinit: Client
$(hostname) not found in Kerberos database".

I then interrogated the realm with adcli, using 'adcli testjoin --verbose' and
it outputs the computer account name as HOST/HOSTNAME@REALM. When I run 'kinit
-k HOST/HOSTNAME@REALM' I get back the error "kinit: Keytab contains no
suitible keys for HOST/HOSTNAME@REALM".

I am confused because when I run 'adcli update --verbose' it says it updated
the keytab at /etc/krb5.keytab and outputs the same account name (which I am
assuming is the principal for the computer) as adcli testjoin. I am really
scratching my head about this, what am I doing wrong here?

Thanks,
Wes

Public Content

The information contained in this e-mail and any attachments from Numerica
Corporation may contain confidential and/or proprietary information, and is
intended only for the named recipient to whom it was originally addressed. If
you are not the intended recipient, any disclosure, distribution, or copying of
this e-mail or its attachments is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by return e-mail and
permanently delete the e-mail and any attachments.

Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

[SSSD-users] Re: [External] - Re: How to authenticate machine with Kerberos to Active Directory?

2020-07-30 Thread Wesley Taylor

Sorry I asked this question in the wrong place, but thank you for the awesome 
answer James!

Public Content

-Original Message-
From: James Ralston 
Sent: Wednesday, July 29, 2020 11:05 PM
To: End-user discussions about the System Security Services Daemon 

Subject: [External] - [SSSD-users] Re: How to authenticate machine with 
Kerberos to Active Directory?

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

On Wed, Jul 29, 2020 at 8:24 PM Wesley Taylor  
wrote:

> I have a program I am trying to set up which tries to authenticate
> with the principal host\machine-FQDN@REALM using Kerberos.
>
> However, when I run kinit -k, the machine isn't found in the Kerberos
> database.

"kinit -k" (with no arguments) defaults to attempting to obtain a TGT for 
(e.g.) host/mymachine.example@example.org, which only works if you set 
userPrincipalName to host/mymachine.example@example.org
when you joined the host to Active Directory.

Running "kinit -k MYMACHINE\$" (that is, using the value of the sAMAccountName 
attribute as the argument to "kinit -k") should always work.

> From what I have read, SSSD is responsible for being the glue between
> MIT Kerberos (what Linux uses) and Microsoft Kerberos (which Active
> Directory uses).

This has nothing to do with sssd; it's all about setting userPrincipalName 
correctly when you join the host to AD if you want "kinit -k" (with no 
arguments) to work.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe 
send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7Cfc44b59ef54b4f35311508d8344620e5%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637316823113865460sdata=9uYFM8UBNAY2btttsNdOcxVHn4HoPsq16EGZIT8%2BzxA%3Dreserved=0
List Guidelines: 
https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7Cfc44b59ef54b4f35311508d8344620e5%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637316823113865460sdata=u%2BYWfJajDCG%2F5GR1mt8kmKtzJPb1bcAr7bYSNrMNHzI%3Dreserved=0
List Archives: 
https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted.orgdata=02%7C01%7C%7Cfc44b59ef54b4f35311508d8344620e5%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637316823113865460sdata=%2FL0QIhBxCfu80Q4FO3SwWdXW0XYP6jo8GpIyoA1uBsw%3Dreserved=0

smime.p7s
Description: S/MIME cryptographic signature
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] How to authenticate machine with Kerberos to Active Directory?

2020-07-29 Thread Wesley Taylor

Hello,

I have a program I am trying to set up which tries to authenticate with the
principal host\machine-FQDN@REALM using Kerberos.

However, when I run kinit -k, the machine isn't found in the Kerberos
database.

The reason I think this question belongs here is I used realm join to
configure Kerberos, SSSD, and PAM automagically to work with an Active
Directory based domain controller. All my domain user accounts are able to
get tickets just fine, but the default Kerberos keytab cannot. From what I
have read, SSSD is responsible for being the glue between MIT Kerberos (what
Linux uses) and Microsoft Kerberos (which Active Directory uses).

I am just scratching my head here on how I can get access to the principal
used by the machine itself to get Kerberos tickets. Is there a good way to
go about this? Is SSSD responsible for this information, or is my domain
controller configured incorrectly for this kind of setup?

Thank you,
Wes



Public Content


smime.p7s
Description: S/MIME cryptographic signature
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [google-appengine] Re: GCP Access

2020-07-22 Thread wesley chun

Agreed. Never (ever) share login/password information. We are well beyond
those days now with role-based authentication
<https://en.wikipedia.org/wiki/Role-based_access_control> and OAuth2
<https://en.wikipedia.org/wiki/OAuth>.

Furthermore, be aware we have multiple compute options available from GCP
in addition to App Engine. If you're considering what's right for you,
check out this informative animation <https://lnkd.in/gkeT3AW>. I recommend
serverless for cost+convenience, containers for flexibility, and Cloud Run
for both!

Cheers,
 --Wesley

On Wed, Jul 22, 2020 at 12:00 PM 'Charlie Engelke' via Google App Engine <
google-appengine@googlegroups.com> wrote:

> Don't share login information. There's no need. You can create a project,
> then add the developer as a user, or owner, of that project in addition to
> you.
>
> On Wednesday, July 22, 2020 at 1:00:44 AM UTC-7 ki...@douglassoftware.com
> wrote:
>
>> I am a non technical founder, what information do i need to give my
>> developer to be able to upload the code to GCP ? Do I need to just hand
>> over my login info to the developer to be able to upload or is there a way
>> of giving the developer access to the account that I have created ?
>
>
-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
wesley chun :: @wescpy <http://twitter.com/wescpy> :: Software
Architect & Engineer
Developer Advocate at Google Cloud by day; at night...
Python training & consulting : http://CyberwebConsulting.com
"Core Python" books : http://CorePython.com
Python blog: http://wescpy.blogspot.com

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

Re: [google-appengine] Re: App Engine doesn't downscale when CPU utilisation is below target_utilization

2020-07-20 Thread wesley chun

This question only applies to Flex users
<https://groups.google.com/forum/#!topic/google-appengine/IWNzceG4FxY>.
According to the documentation
<https://cloud.google.com/appengine/docs/flexible/python/reference/app-yaml#updated_health_checks>,
health check HTTP requests are *not* sent to the container, meaning that it
doesn't affect the autoscaling (up or down) to your app like "real" traffic
to your app. The exception is if you "extended" your health checks to your
app by providing a path to the endpoint you wish to be hit when a health
check is performed. I'm sure you also know that Flex requires *at least* 1
instance being up, so it'll never downscale to zero (see this page
<https://cloud.google.com/appengine/docs/flexible/python/flexible-for-standard-users#scaling_characteristics>
regarding scaling, health checks, and other differences b/w standard &
flexible environments.

Hope this helps!
--Wesley

On Sun, Jul 19, 2020 at 4:26 PM tz martin  wrote:

> Does anyone know if potential health check settings (liveness_check or
> readiness_check) are as requests that would prevent downscaling instances?
> Wondering if health check "bursts" would keep one or all instances alive.
>
> On Tuesday, September 3, 2019 at 2:52:21 PM UTC diogoa...@google.com
> wrote:
>
>> You can use the App Engine custom runtime
>> <https://cloud.google.com/appengine/docs/flexible/custom-runtimes/> to
>> deploy an application in any language.
>>
>> I did not find any documents about Angular 8, but as a starting point you
>> could take a look at this tutorial for deploying Angular 6
>> <https://medium.com/@asanoop24/deploying-angular-6-app-on-google-app-engine-b6259d4c16c2>
>> .
>>
>> As not all use cases can be covered in the App Engine documents I
>> recommend you take request development assistance on Stack Overflow
>> <https://stackoverflow.com/questions/39782506/deploying-basic-angular-2-app-to-google-app-engine/50494337#50494337>,
>> where the community of developers will be able to help you with your
>> Angular coding.
>>
>> On Tuesday, September 3, 2019 at 8:54:41 AM UTC-4, chuda mani wrote:
>>>
>>> hi i need a suggestion , i have to deploy angular 8 application with
>>> apache server in gcp app engine..is it possible?..if so please  forward any
>>> reference documents..thank you
>>>
>>
-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
wesley chun :: @wescpy <http://twitter.com/wescpy> :: Software
Architect & Engineer
Developer Advocate at Google Cloud by day; at night...
Python training & consulting : http://CyberwebConsulting.com
"Core Python" books : http://CorePython.com
Python blog: http://wescpy.blogspot.com

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

Re: [google-appengine] Re: I'm interested to know more about cloud storage free trail under$300

2020-07-20 Thread wesley chun

Hi Kumar, as a beginner to GCP, I generally recommend *against* using the
free trial when exploring the product group. (BTW, in English, there is a
difference between "trial" and "trail".) As Joseph mentioned, there is
an "Always
Free" tier <https://cloud.google.com/free/docs/gcp-free-tier#always-free>
(multiple
GCP products). This daily/monthly free quota for participating products (1
free VM, 5GB disk storage [US region], 2M Cloud Functions calls, etc.) is
always available to developers. As long as you stay under the quota, you
will never be charged for their use.

I recommend you do NOT use the $300USD Free Trial because of 2 main
reasons: 1) the trial lasts exactly 12 months from when you activate it
(the clock starts ticking immediately) and 2) it is a 1-time offer (can't
get it again). You only incur billing by exceeding the Always Free tier
quotas, meaning you don't "eat into" the $300 until that happens. Do your
due diligence, research which GCP tools to use, and *only activate the Free
Trial when your normal usage on GCP consistently exceeds the Always Free
tier*. Otherwise you're not taking full advantage of the offer.

Good luck!
--Wesley

On Mon, Jul 20, 2020 at 10:53 AM 'noverlyjoseph' via Google App Engine <
google-appengine@googlegroups.com> wrote:

> You will only be charged for what you go over the Free Tier depending on
> the services.
> For Cloud Storage for example, as long as you don't go over the Always
> Free limit in your usage, you will not be charged.
> Here's[1] the Always Free usage limits for Cloud Storage.
> For any other services you will find that information in the Pricing
> section of that Service.
>
>
> [1] https://cloud.google.com/storage/pricing#cloud-storage-always-free
>
>
> On Monday, July 20, 2020 at 8:15:10 AM UTC-4, kumar reddy wrote:
>>
>> I just want to know more about $300 free trail. I i get signed up for
>> $300 free trail, and add credit card details., will i be charged for any
>> charges after i consume the services under that package?. will i have a
>> stop point that allows me to stop using the paid services?
>>
>> My intention is to avoid any kind of charges, and continue with free
>> trail to experience the cloud storage.
>>
>> Thanks,
>> Kumar N.
>>
>
-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
wesley chun :: @wescpy <http://twitter.com/wescpy> :: Software
Architect & Engineer
Developer Advocate at Google Cloud by day; at night...
Python training & consulting : http://CyberwebConsulting.com
"Core Python" books : http://CorePython.com
Python blog: http://wescpy.blogspot.com

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

RE: Apple Mac Quadra 700

2020-07-15 Thread Wesley Furr

I had (well, sorta still have) a IIci and a IIcx I picked up some years back
at a thrift store cheap.  Unfortunately that was before I learned of the
dangers of leaking batteries...you can probably guess where this is
leading...not much left of them.  More recently I got a IIcx motherboard
from someone and re-capped it, but still couldn't get it to work...gave up
on it for the time being.  Might have to take another stab at it some
day...but not sure what else to try.  As I recall, the only real difference
in the II's and 700 is that the II's are set up to be in desktop orientation
and the 700 as a tower?  All personal preference...  :-)

I have re-capped a couple of old Macs, mainly LC and LCII's so far.  I found
that the MLCC (multilayer ceramic) capacitors work very well.  Nice and
small (but not too small) with plenty of pad on the board to make them very
easy to solder on.  Also no polarity to worry about.  Sounds like they may
be more reliable than even the tantalum capacitors.  I know what you mean,
shipping is the worst part!  The last ones I got I picked some up from
ebay...US sellers selling some off of a reel or whatever...prices and
shipping both better than from Mouser/Digikey/etc.

Wesley

  _  

From: vintage-macs@googlegroups.com [mailto:vintage-macs@googlegroups.com]
On Behalf Of Thomas Pfaff
Sent: Wednesday, July 15, 2020 8:01 PM
To: vintage-macs@googlegroups.com
Subject: Re: Apple Mac Quadra 700

Hi.  Yep am planning on moving to tantalum in my IIci.
I understood your reply completely... so thank you!

When I worked at Ample Computerz I bought a Quadra 900 among other
machines... they were cheap for employeez.
Turned out they were cheap all around- the case was always falling apart and
meh... so I had planned on getting a Quadra 700 myself.
I quit working there out of disgust gravitated to NeXT work afterward
coz both their hardware+OS software was so much better.  Not to mention NeXT
programmers did less work and were paid a lot more than their Mac
counterparts, by and large, due to the scarcity of Objective-C developers.

Anyway, I found a IIci for next to nothing recently, then remembered the
first Mac I did engineering work on was a IIci (at Everex) and kinda fell in
love with it.
I like the case better than the Quadra 700... even tho' they are nearly
identical.
It's like the Star Trek where Spock says to the two identical chick robots,
"I love you... but I hate you!"
Or something like that.  Hmm.  I don't hate the 700 tho'.  :-)  I do prefer
the IIfx and the IIci models right now.

I have a tentative order in at Mouser for tantalum caps but want to line up
a few more projects coz of the shipping costs!  

Hope I can get that machine working by January.

Incidentally, does anyone have a installed image of A/UX 3.0?  A/UX 2.0?  I
was stupid enough to sell my copy of both, which I got when I was at Ample.
That's what I really want to run again on my Mac II series models.  A/UX 3.x
runs zippity quick on the Quadras but just think the earlier models are
cuter.

Thomas

On Wed, Jul 15, 2020 at 12:35 PM  wrote:

I have a Q700 I picked up at a recycling center and tried a while back  
to get working, but didn't have any luck, but also didn't spend much  
time on it, could be a bad power supply.  At any rate, my recollection  
is that on the one I had at least, the capacitors on the motherboard  
were all the yellow tantalum capacitors, not the silver can  
electrolytic type that fail and leak in the well-known fashion.   
Tantalum capacitors can fail too, I have seen it happen on at least  
two older PC's (I assume it could happen on Macs too)...and they  
either fail silently and likely short out, or they can explode (blow  
the top off) in an impressive pop...I have observed one of each, and  
when they blow, they get your attention.  :-)  But to your original  
question, if it is like mine, and I'm guessing it would be, they are  
the more reliable tantalum capacitors that should not need replacement.

Wesley

Quoting Thomas Pfaff :

> Curious... do you know if the capacitors on the Quadra 700 mamaboard do
> better than the ones in the IIci and such?  Capacitors from the pre-china
> days tend to have very long lifespans but Apple got  an early start on
> shipping "lesser componentry" on their boards.
>
> Thomas

-- 
-- 
-
You received this message because you are a member of the Vintage Macs
group.
The list FAQ is at http://lowendmac.com/lists/vintagemacs.shtml and our
netiquette guide is at http://www.lowendmac.com/lists/netiquette.shtml
To post to this group, send email to vintage-macs@googlegroups.com
To leave this group, send email to vintage-macs+unsubscr...@googlegroups.com
<mailto:vintage-macs%2bunsubscr...@googlegroups.com> 
For more options, visit this group at
http://groups.google.com/group/vintage-macs

Support for older Macs: http://lowendmac.com/services/
--- 
You received this message because you are s

Re: Shell account service providers

2020-07-15 Thread Wesley





Ibsen S Ripsbusker wrote:

Are there services that sell managed OpenBSD shell accounts?
I mean a service similar to sdf.org.


Try google with keywords "online unix terminal for shell scripting", you 
will find a lot results.


regards.

Re: Apple Mac Quadra 700

2020-07-15 Thread wesley

I have a Q700 I picked up at a recycling center and tried a while back  
to get working, but didn't have any luck, but also didn't spend much  
time on it, could be a bad power supply.  At any rate, my recollection  
is that on the one I had at least, the capacitors on the motherboard  
were all the yellow tantalum capacitors, not the silver can  
electrolytic type that fail and leak in the well-known fashion.   
Tantalum capacitors can fail too, I have seen it happen on at least  
two older PC's (I assume it could happen on Macs too)...and they  
either fail silently and likely short out, or they can explode (blow  
the top off) in an impressive pop...I have observed one of each, and  
when they blow, they get your attention.  :-)  But to your original  
question, if it is like mine, and I'm guessing it would be, they are  
the more reliable tantalum capacitors that should not need replacement.


Wesley


Quoting Thomas Pfaff :


Curious... do you know if the capacitors on the Quadra 700 mamaboard do
better than the ones in the IIci and such?  Capacitors from the pre-china
days tend to have very long lifespans but Apple got  an early start on
shipping "lesser componentry" on their boards.

Thomas



--
--
-
You received this message because you are a member of the Vintage Macs group.
The list FAQ is at http://lowendmac.com/lists/vintagemacs.shtml and our 
netiquette guide is at http://www.lowendmac.com/lists/netiquette.shtml
To post to this group, send email to vintage-macs@googlegroups.com
To leave this group, send email to vintage-macs+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/vintage-macs

Support for older Macs: http://lowendmac.com/services/
--- 
You received this message because you are subscribed to the Google Groups "Vintage Macs" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vintage-macs+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vintage-macs/20200715153103.Horde.1XQSrezQzsMWYWE7xVHaz3l%40www.megley.com.

[go-nuts] Ignite go library

2020-07-14 Thread Wesley


Hi

Is there any thin client for Ignite by go?
https://ignite.apache.org/docs-and-apis.html

I didn't see the official one.

Thank you.

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5879d66e-a8af-bdf0-888d-bb5a330f4f9f%40freenetMail.de.

Re: Unsubscribe

2020-07-14 Thread Wesley


please send an empty email to:

user-unsubscr...@cassandra.apache.org

to unsubscribe yourself from the list.

Thank you.

srinivasarao daruna wrote:



Thank You,
Regards,
Srini




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

Bug#964934: cookiecutter: Upgrade to version 1.7.x

2020-07-12 Thread Wesley Schwengle

Package: cookiecutter
Version: 1.6.0-4
Severity: normal

Dear Maintainer,

In December 2019 version 1.7.0 was released and in April 2020 1.7.1 and
1.7.2 were released. It adds a very useful feature:

  https://cookiecutter.readthedocs.io/en/1.7.2/advanced/directories.html

I would like to make use of this. Could you bump the version the debian
unstable branch?

Many thanks,
Wesley


-- System Information:
Debian Release: bullseye/sid
  APT prefers stable
  APT policy: (10, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cookiecutter depends on:
ii  python3   3.8.2-3
ii  python3-cookiecutter  1.6.0-4

cookiecutter recommends no packages.

Versions of packages cookiecutter suggests:
pn  python-cookiecutter-doc  

-- no debconf information

[ovirt-users] Re: RDP

2020-07-12 Thread Wesley Stewart

Are you asking for troubleshooting on getting windows RDP working in a
windows 10 guest?

Shouldn't have anything to do with ovirt.  Do you have a local admin
account with the same credentials?  That would explain why it works.

To test, make a test user, make it an administrator and try instead of an
RDP user group.  Sounds like a permission issue.


On Sun, Jul 12, 2020, 10:16 AM  wrote:

> I am using Ovirt 4.3. I followed the instructions for get RDP to work for
> a user, but admin@internal is the only user the RDP will launch for. The
> other test users I created and are added to the Remote Desktop Users group
> which is the permission I assigned to the VM's as well as the user name. I
> added users first, then the group to see if it would help.
> So far, admin@internal, the Ovirt admin user, is the only user RDP will
> work for.
> I know I am missing something, I'm just not sure what.
> Any help would be appreciated.
> Eric.
> ___
> 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/BFGTKML43R6PY27FTFVDM2PNROHMLPQI/
>
___
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/L2IT2VBEF6UGSXB4QKACNOSEYI75NOA6/

[Spice-devel] last known good spice guest tools for WinXP guest?

2020-07-12 Thread Wesley Parish

Hi

I've got a Windows XP guest in a Gnome Box and I'm wondering which of
the earlier releases of the spice guest tools is known to work well
with Windows XP. It's a 64-bit, though I'm also intending to install
32-bit as well. (I've tried installing spice-guest-tools-latest but it
refuses to install.)

My OS is Fedora 31, x86_64, and the Gnome Boxes release is 3.36.

Thanks

Wesley Parish
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [rdo-dev] RDO Cloud operations today

2020-07-10 Thread Wesley Hayutin

On Fri, Jul 10, 2020 at 1:46 AM Alan Pevec  wrote:

> > last update as of few hours ago was: rdocloud networking should be now
> > stable, uplink is not redundant, IT will work on getting back failover
> > during the day
>
> Update as of this morning:
> uplink redundancy was restored last night,
> restoring full CI pool is planned today.
>
> Cheers,
> Alan
>

Good news.. thank you
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

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

Re: I Became a Solr Committer in 4662 Days. Here’s how you can do it faster!

2020-07-10 Thread Wesley


thanks for share. nice article.


Charlie Hull wrote:
Thought you might enjoy Eric's blog, it's taken him a while! Some good 
hints here for those of you interested in contributing more to Solr.


https://opensourceconnections.com/blog/2020/07/10/i-became-a-solr-committer-in-4662-days-heres-how-you-can-do-it-faster/

Re: Unsubscribe

2020-07-09 Thread Wesley

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


regards.

Greg Bone wrote:

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

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

2020-07-09 Thread Wesley Cheng

On 7/9/2020 3:46 PM, Rob Herring wrote:
> 
> Why is all the connector schema duplicated here? You only need things 
> that are further constrained like 'compatible'.
> 

Hi Rob,

Most of the properties in this dt-binding are going to be constrained by
the definitions/values specified by usb-connector.  I can add individual
references to each property, such as compatible, power-role, data-role
and ports, if that is the recommended approach.

> 
> 'remote-endpoint' in not an array.
> 

Agreed, I have removed the maxItems parameter.

> 
> So USB-SS data can come from 'type C mux' or 'role switch node'? That 
> seems odd.
> 

This was one of the interpretations, which might work with the current
usb-connector model.  From the previous block diagram I shared, we can
see that the SS path has two potential "endpoints," one to the mux and
another to the USB controller on the SOC.

Another design consideration is when the device supports the "Audio
Adapter Accessory Mode."  The audio accessory is mentioned in the type C
spec as an adapter which will utilize the USB D+/- lines for audio
output.  So now, you could potentially have something like below:

   ___   ___
__|FUSB302| |SOC|
   |  |Type C | |   |
   |  |Cntrl  |__I2C___ |   |
   |  |___| |   |
 ___   ||   |
|   |__ CC1/2 _||   |
|   |  ___  |   |
|   |*|Charger| |   |
|   |   | |HW | |   |
|   |   | |___| |   |
|   |   |   |   |
|   |__ HS DP/DM ___|*|MAX20328|_HS D+/D-__ |   |
|   | ||__Audio Out_|   |
|   |   |   |
|   |__ SS RX/TX1 __**|FUSB304 |_SS RX/TX**_|   |
|   |__ SS RX/TX2 |USB Mux ||___|
|   | ||
|   |
|___|

With this kind of device, it would make sense to have multiple endpoints
per path, which can be represented like the following:

connector {
compatible = "usb-c-connector";
...
ports {
port@0 {
...
//Charger endpoint*
usb_con_hs_chg: endpoint@0 {
reg = <0>;
remote-endpoint = <_usbc_hs>;
};
//Audio accessory adapter mux*
usb_con_hs_audio: endpoint@1 {
reg = <1>;
remote-endpoint = <_audio>;
};
};
port@1 {
...
//USB3 lane mux**
usb3_data_ss: endpoint@0 {
reg = <0>;
remote-endpoint = <_ss_mux>;
};
//USB3 SOC controller**
usb3_role: endpoint@1 {
reg = <1>;
remote-endpoint = <_drd_switch>;
};
};
};
};

Thanks
Wesley Cheng

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

Re: [rdo-dev] RDO Cloud operations today

2020-07-09 Thread Wesley Hayutin

On Wed, Jul 8, 2020 at 5:11 AM Alan Pevec  wrote:

> Hi all,
>
> FYI RDO Cloud is undergoing scheduled movement of some of its racks,
> control plane and infra services (www, lists, CI pool) should stay up
> all the time.
> In case of unplanned outage we'll let you know in this thread and also
> announce when those operations are finished.
> At one point there will be reduced CI pool capacity, so expect to see
> longer queues in https://review.rdoproject.org/zuul/status during the
> day.
>
> Cheers,
> Alan
>
>
Any updates on the status of the operations?


> ___
> dev mailing list
> dev@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
>
>
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

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

Re: [ANNOUNCE] Apache Flink 1.11.0 released

2020-07-07 Thread Wesley


Nice news. Congrats!


Leonard Xu wrote:

Congratulations!

Thanks Zhijiang and Piotr for the great work, and thanks everyone involved!

Best,
Leonard Xu

Re: PE rule matches when run under yara-python but not in yara ??!

2020-07-07 Thread Wesley Shields

I can't replicate this - it does not match on 4.0.2 on my system. There is no 
rule parsing bug here - the same C code is used when compiling rules using yara 
on the command line or via python. I've had a couple of people tell me 
something weird is going on when using pip to install yara-python, especially 
if you have an older install of libyara laying around. It's almost as if it 
isn't picking up the bundled version of yara and is instead falling back to 
whatever you have laying around. You commented out the printing of the version 
in your python snippet, but just to confirm that is printing the correct 
version of yara?

To be clear, I think this is a local problem and your evaluation is possibly 
incorrect. I think the bug is that it DOES match under yara-python when it 
should not. It not matching when running yara from the command line is the 
correct behavior (I think).

-- WXS

> On Jul 7, 2020, at 2:10 PM, Wes Hurd <13hu...@gmail.com> wrote:
> 
> Hi, 
> 
> This is running with the following versions on macOS 10.14.6:
> 
> yara 4.0.2 homebrew
> 
> yara-python 4.0.2 (pip) 
> Python 3.7.7
> 
> I'm having a really weird case where a rule using pe module is unexpectedly 
> matching certain files when run under yara-python , but not matching if 
> running the yara binary directly.
> 
> Running on this PE file: 
> https://www.virustotal.com/gui/file/154f5cbaafabba2133f8f4578c7e25f3d42d18ff7fc61fab005436d63a3cfee8/details
>  
> 
> "test_odd_pe_py_match.yara":
> rule Odd_PE_Entry_Point
> {
> condition:
> uint16(0) == 0x5a4d and
> ((pe.entry_point >= pe.sections[pe.number_of_sections - 
> 1].raw_data_offset) or (not 
> pe.sections[pe.section_index(pe.entry_point)].name contains ".text"))
> }
> 
> 
> 
> Python :
> import yara
> #print(yara.__version__)
> 
> try:
> scan = yara.compile("./test_odd_pe_py_match.yara")
> except yara.Error as e:
> print("YARA compile error:", e)
> 
> matches = 
> scan.match(filepath="154f5cbaafabba2133f8f4578c7e25f3d42d18ff7fc61fab005436d63a3cfee8.exe")
> print(matches)
> 
> [Odd_PE_Entry_Point]
> 
> 
> yara bin:
> $ yara test_odd_pe_py_match.yara 
> 154f5cbaafabba2133f8f4578c7e25f3d42d18ff7fc61fab005436d63a3cfee8.exe
> 
> $
> No matches
> 
> 
> Can someone tell what's going on here ? 
> It seems to me there is some sort of either rule parsing bug under python, or 
> race condition that causes the python run to match when the binary doesn't.
> 
> Thanks,
> 
> 
> -- 
> 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/48c4b198-182b-4f28-aecd-90db120ef1c8o%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/4BA5B724-FCC0-4854-BCCD-5D06F2D150F2%40atarininja.org.

Re: Matching only fullword standalone base64 strings (ending in '==') ?

2020-07-07 Thread Wesley Shields

I don't think fullword makes sense here, given that the base64 modifiers are 
meant to work when the string you're searching for is embedded anywhere in a 
base64 encoded string. This requires that it strip some leading and trailing 
bytes. If you want to find it without this behavior just put the base64 string 
in as a literal and don't use the modifiers. A quick comment about what it is 
in decoded form will help readability.

-- WXS

> On Jul 7, 2020, at 2:34 PM, Wes Hurd <13hu...@gmail.com> wrote:
> 
> Hi again,
> 
> I'm wondering if there is a way to match Base64 strings only when they are 
> 'fullword', standalone.
> 
> For example:
> rule base64_Example
> {
> strings:
> $s = "setsockopt" base64 base64wide // c2V0c29ja29wdA==
> condition:
> $s
> }
> 
> 
> This rule will match anything containing the string "c2V0c29ja29wdA"
> What if I want it to only match on the standalone base64 string 
> "c2V0c29ja29wdA==" ? 
> Obviously I could match that string literal but I was curious if it would 
> make sense for base64 to do this, for readability and flexibility ? 
> 
> Using fullword with base64 modifiers does not seem to be supported.
> invalid modifier combination "base64 fullword"
> 
> Thank you, 
> 
>  - Wes
> 
> 
> -- 
> 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/e160da25-1de2-4f07-bcd3-31ae0c50b779o%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/393AD2E4-B029-4338-8ED6-0AC5E8BFCE15%40atarininja.org.

Re: [prometheus-users] JMX exporter problem, can't run process

2020-07-06 Thread Wesley


what's the log and error message?

Jacek 1974 wrote:

Anybody?


--
You received this message because you are subscribed to the Google Groups 
"Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-users/6e1ae167-1c31-49d9-0f34-cda03ca2e885%40freenetMail.de.

Re: Blog of jdbc interpreter on zeppelin

2020-07-06 Thread Wesley





Jeff Zhang wrote:
I write a article about jdbc interpreter on zeppelin, hope it is helpful 
for you.


https://medium.com/@zjffdu/jdbc-interpreter-on-zeppelin-tutorial-8a7958b8c94e



Nice article. Thanks for share.

regards.

Re: [plonegov-br] Permissão de usuário

2020-07-04 Thread Wesley Lopes

Marco dá uma olhada aqui:

https://github.com/collective/collective.cover/issues/855

Em sex., 3 de jul. de 2020 às 12:42, Carolina Machay <
carolina.mac...@gmail.com> escreveu:

> Obrigada.
>
> Em sex., 3 de jul. de 2020 às 11:58, André Nogueira 
> escreveu:
>
>> Carolina,
>>
>> A ideia desse perfil é alguém que possa justamente para alguém que possa
>> fazer esse tipo de configuração.
>> Por que você não cria um novo perfil para a função que deseja? Pode te
>> poupar dores de cabeça no futuro.
>>
>> []s
>> André
>>
>> Em qui., 2 de jul. de 2020 às 17:38, Carolina Machay <
>> carolina.mac...@gmail.com> escreveu:
>>
>>> Boa tarde.
>>> Seria possível configurar para que a permissão do "Site Admnistrador"
>>> não tenha acesso às configurações do site?
>>>
>>> Muito obrigada.
>>> --
>>> 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
-- 
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

[PATCH v5 4/6] regulator: Add support for QCOM PMIC VBUS booster

Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals.  This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.

Signed-off-by: Wesley Cheng 
---
 drivers/regulator/Kconfig   | 10 +++
 drivers/regulator/Makefile  |  1 +
 drivers/regulator/qcom_usb_vbus-regulator.c | 97 +
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 074a2ef55943..273d85a45263 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -797,6 +797,16 @@ config REGULATOR_QCOM_SPMI
  Qualcomm SPMI PMICs as a module. The module will be named
  "qcom_spmi-regulator".
 
+config REGULATOR_QCOM_USB_VBUS
+   tristate "Qualcomm USB Vbus regulator driver"
+   depends on SPMI || COMPILE_TEST
+   help
+ If you say yes to this option, support will be included for the
+ regulator used to enable the VBUS output.
+
+ Say M here if you want to include support for enabling the VBUS output
+ as a module. The module will be named "qcom_usb_vbus_regulator".
+
 config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c0d6b96ebd78..cbab28aa7b56 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
diff --git a/drivers/regulator/qcom_usb_vbus-regulator.c 
b/drivers/regulator/qcom_usb_vbus-regulator.c
new file mode 100644
index ..342d92373598
--- /dev/null
+++ b/drivers/regulator/qcom_usb_vbus-regulator.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Qualcomm PMIC VBUS output regulator driver
+//
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMD_OTG0x40
+#define OTG_EN BIT(0)
+#define OTG_CFG0x53
+#define OTG_EN_SRC_CFG BIT(1)
+
+static const struct regulator_ops qcom_usb_vbus_reg_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+
+static struct regulator_desc qcom_usb_vbus_rdesc = {
+   .name = "usb_vbus",
+   .ops = _usb_vbus_reg_ops,
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+};
+
+static int qcom_usb_vbus_regulator_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct regulator_dev *rdev;
+   struct regmap *regmap;
+   struct regulator_config config = { };
+   struct regulator_init_data *init_data;
+   int ret;
+   u32 base;
+
+   ret = of_property_read_u32(dev->of_node, "reg", );
+   if (ret < 0) {
+   dev_err(dev, "no base address found\n");
+   return ret;
+   }
+
+   regmap = dev_get_regmap(dev->parent, NULL);
+   if (regmap) {
+   dev_err(dev, "Failed to get regmap\n");
+   return -ENOENT;
+   }
+
+   init_data = of_get_regulator_init_data(dev, dev->of_node,
+  _usb_vbus_rdesc);
+   if (!init_data)
+   return -ENOMEM;
+
+   qcom_usb_vbus_rdesc.enable_reg = base + CMD_OTG;
+   qcom_usb_vbus_rdesc.enable_mask = OTG_EN;
+   config.dev = dev;
+   config.init_data = init_data;
+   config.regmap = regmap;
+
+   rdev = devm_regulator_register(dev, _usb_vbus_rdesc, );
+   if (IS_ERR(rdev)) {
+   ret = PTR_ERR(rdev);
+   dev_err(dev, "not able to register vbus reg %d\n", ret);
+   return ret;
+   }
+
+   /* Disable HW logic for VBUS enable */
+   regmap_update_bits(regmap, base + OTG_CFG, OTG_EN_SRC_CFG, 0);
+
+   return 0;
+}
+
+static const struct of_device_id qcom_usb_vbus_regulator_match[] = {
+   { .compatible = "qcom,pm8150b-vbus-reg" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, qcom_usb_vbus_regulator_match);
+
+static struct platform_driver qcom_usb_vbus_regulator_driver = {
+   .driver = {
+

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

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

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

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

[PATCH v5 0/6] Introduce PMIC based USB type C detection

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

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

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

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

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

 .../regulator/qcom,usb-vbus-regulator.yaml|  41 +++
 .../bindings/usb/qcom,pmic-typec.yaml | 130 +
 arch/arm64/boot/dts/qcom/pm8150b.dtsi |  13 +
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts   |   4 +
 drivers/regulator/Kconfig |  10 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c   |  97 ++
 drivers/usb/typec/Kconfig |  12 +
 drivers/usb/typec/Makefile|   1 +
 drivers/usb/typec/qcom-pmic-typec.c   | 275 ++
 10 files changed, 584 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

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

[PATCH v5 1/6] usb: typec: Add QCOM PMIC typec detection driver

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

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

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

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

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

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

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

[PATCH v5 5/6] dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator

This describes how to enable the Qualcomm PMIC VBUS booster used for
providing power to connected USB peripherals when the USB role is host
mode.  The driver itself will register the vbus_usb regulator, so that
external drivers can utilize the enable/disable regulator APIs.

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

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
new file mode 100644
index ..12ed98c28aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Qualcomm PMIC VBUS output regulator driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  This regulator driver controls the VBUS output by the Qualcomm PMIC.  This
+  regulator will be enabled in situations where the device is required to
+  provide power to the connected peripheral.
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-vbus-reg
+
+  reg:
+maxItems: 1
+description: VBUS output base address
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+ pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+pm8150b_vbus: dcdc@1100 {
+compatible = "qcom,pm8150b-vbus-reg";
+reg = <0x1100>;
+};
+ };
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

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

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

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 322379d5c31f..91b870345dda 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,13 @@ power-on@800 {
status = "disabled";
};
 
+   pm8150b_typec: typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   status = "disabled";
+   reg = <0x1500>;
+   interrupts = <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: PE module: 'not' logic conditions will match on non-PE files - should pe functions first check if file is PE ?

2020-07-01 Thread Wesley Shields

This is likely due to the change made recently where comparing with UNDEFINED 
values now evaluates to false. It used to evaluate to UNDEFINED.

> But shouldn't pe module conditions check first if the file is a PE header or 
> valid base PE, then fail if the file isn't ?

Functions in the pe module do check if they are accessing UNDEFINED fields and 
return UNDEFINED accordingly. This is the behavior of things like 
"pe.exports()" and others. In your case you have a couple of things going on...

1) You are using "pe.section_index()" which will return UNDEFINED on a non-PE 
file. This means you are accessing pe.sections[UNDEFINED] which is also 
UNDEFINED.

2) You are then accessing the name attribute of an UNDEFINED value which is 
also resulting in an UNDEFINED value.

3) You end up with 'not UNDEFINED contains ".text"' which as of a somewhat 
recent change evaluates to "not false".

This is all because of a recent change where comparisons (including contains) 
with UNDEFINED values result in false.

It's arguable that this is the right change (and to be honest, I don't remember 
why it was changed) but one thing you can do is prefix your condition with 
"pe.is_pe and ..."

-- WXS

> On Jul 1, 2020, at 2:34 PM, Wes Hurd <13hu...@gmail.com> wrote:
> 
> Hi,
> 
> Wanted to post here before raising an issue on github project:
> 
> To reproduce:
> import "pe"
> 
> rule pe_on_nonpe
> {
> condition:
>   not pe.sections[pe.section_index(pe.entry_point)].name contains ".text"
> }
> 
> 
> 
> Run on non-PE file (e.g. Excel document zip)
> yara pe_on_nonpe.yara excel_doc.xlsx
> The rule matches on non-PE files
> 
> But shouldn't pe module conditions check first if the file is a PE header or 
> valid base PE, then fail if the file isn't ? 
> So pe.sections implies the file is PE, does check for valid PE first 
> 
> Regards,
> 
> 
> -- 
> 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/558ba95d-4f7c-4bd7-a8bb-71fab8c97db0o%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/8BDBC9BC-BC20-43F3-86E7-2915154EB077%40atarininja.org.

Re: [casper] Compiling for roach2 on RHEL7

2020-06-30 Thread Wesley New

As someone who has tried plenty of combinations of Matlab, Xilinx and OS
versions over the years with varying success. I would recommend installing
a VM with the supported versions. If you are keen to maximize compile
resources try using lxc or chroot.

Good luck.

On Tue, 30 Jun 2020, 10:55 PM Jonathon Kocz,  wrote:

> Hi Michael,
>
> You might be able to get 2014b to play nicely with the toolflow, but 2013b
> was the last supported version for ISE 14.7, so it would be better to go
> with that if you can. What sort of OS errors are you getting?
>
> One alternative, if you can't get RHEL to work, might be to create a VM of
> e.g. ubuntu 16.04 or similar to spin up when you need to do ROACH2 work.
>
> Cheers,
> Jonathon
>
>
>
> On Tue, 30 Jun 2020 at 13:29, Michael D'Cruze <
> michael.dcr...@manchester.ac.uk> wrote:
>
>> Hi everyone,
>>
>>
>>
>> I’m clutching at straws a little, but I’ve recently obtained a RHEL7
>> system for use with the Vivado toolflow. What we’d really like is to be
>> able to compile models using the “old” ISE toolflow on this new machine. I
>> wondered if anyone had been able to make this happen? I’ve got RHEL 7.8,
>> various Matlab versions, and ISE 14.7.
>>
>>
>>
>> There appear to be some fairly fundamental compatibility issues between
>> the OS and Matlab versions prior to 2014b, though I’m going to ask our
>> local IT support to look at this. Versions at least 2016b and later throw a
>> tantrum when casper_xps is run. 2014b is the most promising at the moment,
>> getting a fair way through casper_xps before complaining about certain
>> Matlab files requiring absolute paths. An internet search doesn’t yield
>> anything promising.
>>
>>
>>
>> Anyway, if you’ve been able to make a combination similar to what I’ve
>> got work correctly, please get in touch.
>>
>>
>>
>> Thanks!
>> Michael
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/DB6PR0102MB263086FDADB5B0F733879740AC6F0%40DB6PR0102MB2630.eurprd01.prod.exchangelabs.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P-Jt8Ua8LGeaTp5SLM04aEhCk9-wDE1i8p%3DqJfoVb_ftA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAE2vkmUtocNgRvZzEkrCgU2hvfPqg_NuyZfS4ry4Wrg0-xKeOw%40mail.gmail.com.

[Mpi-forum] Agenda / Votes for 2020-07-01

2020-06-30 Thread Wesley Bland via mpi-forum

Hi all,

Thanks for another good virtual meeting today. The schedule of plenaries and 
votes for tomorrow has been updated after today’s readings to include necessary 
no-no readings and to add and remove votes as necessary.

So tomorrow morning before the voting block, there will be these no-no readings:

#167: Dan - Error - Section 3.3.2 - p. 38 - Replace C process (no-no)
#252: Dan - Clarification - Section 3.2.2 - p. 27 - Datatype Footnote (no-no)
#190: Dan - Update - Section 3.7.5 - p. 60 - Replace C-bias with LIS (no-no)

These readings are considered complete along with the no-no changes made during 
the reading itself (do not require a no-no reading):

#263: Wesley - Clarification - Section 11.7 - p. 482 - MPI Exception 
Clarification (no-no)
#181: George - Oversight - Section 8.7 - p. 383 - Escape Spaces in Arguments 
(no-no)
#254: George - Clarification - Example 4.17 - p. 128 - Example Comment (no-no)

These readings will be voted on as originally read:

#179: Joseph - Omission - p. 440 - WIN_DETATCH Binding Fix (errata)
#178: Joseph - Omission - p. 439 - WIN_ATTACH_ Binding Fix (errata)
#218: Wesley - Update - Section 17.1 - p. 635 - Update Backward Incompatibility 
Text (errata)
#262: Wesley - Clarification - Section 11.3.5 - p. 458 - Error in Status Field 
Clarification (errata)
#171: George - Error in text - Section 4.1.1 - p. 87 - INTEGER*8 Extension 
(errata)
#257: Julien - Clarification - Section 5.1 - p. 144 - Collective 
Synchronization (errata)
#182: Julien - Question - Section 5.12.4 - p. 206 - MPI_ISCATTERV sendcounts 
and displs Consistency (errata)

You can find the sample ballot for tomorrow here: 
https://www.jotform.com/build/201614072992151 
<https://www.jotform.com/build/201614072992151> 

After the voting block starts, we’ll do the following plenaries in this order:

Reading - 120 - MPI_Cart_create_weighted / Topology aware Cartesian 
communicators - Rolf
Errata Readings - Read all errata tickets up for vote in the order of above
Reading - 57 - Deprecate MPI_HOST - Julien
Reading - 259 - Clarification - Section 8.5 - p. 377 - Error Class and Code 
Advice to Implementors - Wesley
Discussion - Next Meeting(s) and Timeline - Martin

As you can see, we still have quite a few things we need to complete tomorrow 
so we’ll be starting on time and moving quickly. I’d encourage minor comments 
(e.g. typos and small word-smithing discussions) to use GitHub to allow time 
for all of the topics.

If anyone has any corrections for the list above, please let Martin and I know 
and we’ll get everything updated.

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

Re: Apache Beam a Complete Guide - Review?

2020-06-29 Thread Wesley Peng





Rion Williams wrote:

The three authors of Streaming Systems are folks that work on Google’s Dataflow 
Project, which for all intents and purposes is essentially an implementation of 
the Beam Model. Two of them are members of the Beam PMC (essentially a steering 
committee for the project) and you’ll frequently see them if you are active 
within the mailing lists here.

As mentioned earlier in the thread, I can’t recommend Streaming Systems enough. 
If you are curious about Beam or want to dig into it, it’s the best book you’ll 
find on the topic.


Thanks for this info Rion.

Re: Apache Beam a Complete Guide - Review?

2020-06-29 Thread Wesley Peng


Hi Luke

Luke Cwik wrote:
The author for Apache Beam A Complete Guide does not have good reviews 
on Amazon for their other books and as you mentioned no reviews for this 
one.


I would second the Streaming Systems book as the authors directly worked 
on Apache Beam.



So, can Apache beam team in google write a book directly for the project 
users?


Thanks.

RE: [cayugabirds-l] Bobolinks

2020-06-29 Thread Wesley M. Hochachka

I have a small amount of first-hand experience of searching for Bobolink nests 
during a study of the effects of habitat fragmentation on nesting success.  My 
impression is that Bobolink nests can be extremely difficult to find, and I 
would discourage attempts to find a Bobolink nest for the purpose of casual 
observation.  Adult Bobolinks have several behaviors that make nest finding 
difficult, including:

  *   Male activity is only loosely associated with nest locations.  A male can 
be activity singing in one area, actively foraging in another, and with their 
nest in yet another area entirely, within an overall area of several acres.
  *   Female Bobolinks can walk for tens of yards, both to and from their 
nests, making the location at which a female lands only a loose indicator of 
where her nest actually is.
  *   Localizing a nest is potentially best done by flushing a female from her 
nest (so that she has no time to walk away before taking flight).  Flushing 
birds of their nests is a standard methodology for grassland bird researchers, 
using a rope dragged through the grass between two people walking parallel 
lines.

In summary, just finding a Bobolink nest can take a substantial amount of time 
(hours), and cause major damage to habitat in the general vicinity of a nest 
(and potentially result in destruction of the nest).  Personally, I think that 
the potential costs to attempting to find a nest would on average outweigh any 
benefits.  Having written that, the nests of some individual birds are much 
easier to find than would be typical for a species, although I cannot think of 
any way to predict from birds’ behavior when a nest could be easily found 
(except maybe when the nestlings are so old and loud that they would be 
fledging imminently).

Wesley Hochachka




From: bounce-124741359-3494...@list.cornell.edu 
 On Behalf Of Susan Henne
Sent: Monday, June 29, 2020 5:05 PM
To: CAYUGABIRDS-L 
Subject: [cayugabirds-l] Bobolinks

For almost 10 days, there has been a male Bobolink in a meadow in front of my 
house.  I would assume there is a nest in the thick of the tall grass as his 
vocalizations usually get a busy response.  I have yet to see or ID a female or 
young.  The grass is tall and quite dense so maybe this will be the secret to 
their successful brood.  Has anyone had experience observing nestlings?  Can 
anyone suggest some good resources about their behavior?

Thanks
Sue Henne
Ellis Hollow

--
Cayugabirds-L List Info:
Welcome and Basics<http://www.northeastbirding.com/CayugabirdsWELCOME>
Rules and Information<http://www.northeastbirding.com/CayugabirdsRULES>
Subscribe, Configuration and 
Leave<http://www.northeastbirding.com/CayugabirdsSubscribeConfigurationLeave.htm>
Archives:
The Mail 
Archive<http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html>
Surfbirds<http://www.surfbirds.com/birdingmail/Group/Cayugabirds>
BirdingOnThe.Net<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: [Mpi-forum] Agenda and Ballots for Tomorrow

2020-06-29 Thread Wesley Bland via mpi-forum

One quick addendum / clarification to this:

We will not have the first vote on "#120 - MPI_Cart_create_weighted / Topology 
aware Cartesian communicators” on Tuesday. We will only have the “no-no” vote 
on Tuesday.

If the “no-no” vote passes on Tuesday, we will have the first vote for "#120 - 
MPI_Cart_create_weighted / Topology aware Cartesian communicators” on Wednesday.

If there’s any confusion, you can see the two ballots here:

Tuesday - https://www.jotform.com/build/201804215921143 
<https://www.jotform.com/build/201804215921143>
Wednesday - https://www.jotform.com/build/201614072992151 
<https://www.jotform.com/build/201614072992151>

Note that you can’t actually vote yet. Your personalized link for voting will 
be sent out tomorrow during the voting block.

Thanks,
Wes

> On Jun 29, 2020, at 2:00 PM, Martin Schulz via mpi-forum 
>  wrote:
> 
> Hi all,
> 
> Thanks for a first, quite productive session today.
> 
> Just a quick preview for tomorrow: we will start with a discussion on ticket 
> #120 by Rolf and the proposed NoNo Vote text. 
> 
> The voting block will open at 9:30 and will stay open until 10:00, at which 
> time Wesley will announce the results - for the block tomorrow, we’ll include 
> the procedural votes, the NoNos, as well as all first and second votes. If 
> you are the owner of one of those, please be prepared to briefly introduce 
> it, if requested. 
> 
> For the rest of the day, we will then focus on errata readings, so we can 
> vote on them on Wednesday. The agenda lists the order - we grouped them by 
> owner, so we don’t have to switch speakers that often - please take a look at 
> this if you own an errata ticket.
> 
> Thanks and talk to you all tomorrow,
> 
> 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
> 
> ___
> 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

[UPDATE] crystal-0.35.1

2020-06-29 Thread Wesley Moxam

Updates lang/crystal port to v0.35.1

Crystal is working towards a v1.0 release, and v0.35 brought some small
language changes and some polish to the stdlib.

It's worth noting that Crystal Shards now depends on crystal-molinillo
(which is a shard).

-- W


crystal-0.35.1.diff
Description: Binary data

Re: Apache Beam a Complete Guide - Review?

2020-06-28 Thread Wesley Peng


Hi Rion

Rion Williams wrote:
I considered that one as well but was in the same boat in terms of not 
pulling the trigger (lack of reviews, price point, etc.). I eventually 
landed on Streaming Systems, which I highly, highly recommend if you 
want to learn more about the Beam model:


- http://streamingsystems.net/

I don’t think there’s a better book that I’ve come across that focuses 
on it more (and if there is one, I’d love to know about it). I wrote a 
blog post that includes a short-review of it if you want a slightly 
longer summary (http://rion.io/2020/05/09/an-education-in-streaming/), 
but again - I highly recommend checking it out if you hadn’t already.


Thanks for the answer. I will check the resource you gave above.

Regards.

Apache Beam a Complete Guide - Review?

2020-06-28 Thread Wesley Peng


Hello

Has anyone bought this book? Can you give a simple review, good or not?

https://www.thriftbooks.com/w/apache-beam-a-complete-guide---2020-edition/26243355/item/36997139/

I want to buy a book for beam the specific topic, but this book seems 
too new to have enough reviews.


Thanks.

Re: [prometheus-users] Re: not able to see metrics from query browser even though end point is up and showing metrics through curl

2020-06-28 Thread Wesley Peng


Hi

Brian Candler wrote:

"up" missing - scraping not configured.
"up" has value 0 - unable to communicate or data is bad.
"up" has value 1 - maybe partial scrape

Check logs at prometheus and exporter; check traffic between prometheus 
and exporter with tcpdump.


Can you show a sample tcpdump syntax for this purpose?

Thanks.

--
You received this message because you are subscribed to the Google Groups 
"Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-users/130d9158-d6d7-f49f-1884-b2dd1f66e314%40pobox.com.

Re: unsubscribe

2020-06-27 Thread Wesley Peng

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



Sri Kris wrote:
Sent from Mail  for 
Windows 10




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

[PATCH v4 0/6] Introduce PMIC based USB type C detection

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

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

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

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

 .../regulator/qcom,usb-vbus-regulator.yaml|  41 +++
 .../bindings/usb/qcom,pmic-typec.yaml | 113 +++
 arch/arm64/boot/dts/qcom/pm8150b.dtsi |  13 +
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts   |   4 +
 drivers/regulator/Kconfig |  10 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c   |  97 ++
 drivers/usb/typec/Kconfig |  12 +
 drivers/usb/typec/Makefile|   1 +
 drivers/usb/typec/qcom-pmic-typec.c   | 275 ++
 10 files changed, 567 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

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

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

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

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

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

[PATCH v4 4/6] regulator: Add support for QCOM PMIC VBUS booster

Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals.  This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.

Signed-off-by: Wesley Cheng 
---
 drivers/regulator/Kconfig   | 10 +++
 drivers/regulator/Makefile  |  1 +
 drivers/regulator/qcom_usb_vbus-regulator.c | 97 +
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 074a2ef55943..273d85a45263 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -797,6 +797,16 @@ config REGULATOR_QCOM_SPMI
  Qualcomm SPMI PMICs as a module. The module will be named
  "qcom_spmi-regulator".
 
+config REGULATOR_QCOM_USB_VBUS
+   tristate "Qualcomm USB Vbus regulator driver"
+   depends on SPMI || COMPILE_TEST
+   help
+ If you say yes to this option, support will be included for the
+ regulator used to enable the VBUS output.
+
+ Say M here if you want to include support for enabling the VBUS output
+ as a module. The module will be named "qcom_usb_vbus_regulator".
+
 config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c0d6b96ebd78..cbab28aa7b56 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
diff --git a/drivers/regulator/qcom_usb_vbus-regulator.c 
b/drivers/regulator/qcom_usb_vbus-regulator.c
new file mode 100644
index ..342d92373598
--- /dev/null
+++ b/drivers/regulator/qcom_usb_vbus-regulator.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Qualcomm PMIC VBUS output regulator driver
+//
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMD_OTG0x40
+#define OTG_EN BIT(0)
+#define OTG_CFG0x53
+#define OTG_EN_SRC_CFG BIT(1)
+
+static const struct regulator_ops qcom_usb_vbus_reg_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+
+static struct regulator_desc qcom_usb_vbus_rdesc = {
+   .name = "usb_vbus",
+   .ops = _usb_vbus_reg_ops,
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+};
+
+static int qcom_usb_vbus_regulator_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct regulator_dev *rdev;
+   struct regmap *regmap;
+   struct regulator_config config = { };
+   struct regulator_init_data *init_data;
+   int ret;
+   u32 base;
+
+   ret = of_property_read_u32(dev->of_node, "reg", );
+   if (ret < 0) {
+   dev_err(dev, "no base address found\n");
+   return ret;
+   }
+
+   regmap = dev_get_regmap(dev->parent, NULL);
+   if (regmap) {
+   dev_err(dev, "Failed to get regmap\n");
+   return -ENOENT;
+   }
+
+   init_data = of_get_regulator_init_data(dev, dev->of_node,
+  _usb_vbus_rdesc);
+   if (!init_data)
+   return -ENOMEM;
+
+   qcom_usb_vbus_rdesc.enable_reg = base + CMD_OTG;
+   qcom_usb_vbus_rdesc.enable_mask = OTG_EN;
+   config.dev = dev;
+   config.init_data = init_data;
+   config.regmap = regmap;
+
+   rdev = devm_regulator_register(dev, _usb_vbus_rdesc, );
+   if (IS_ERR(rdev)) {
+   ret = PTR_ERR(rdev);
+   dev_err(dev, "not able to register vbus reg %d\n", ret);
+   return ret;
+   }
+
+   /* Disable HW logic for VBUS enable */
+   regmap_update_bits(regmap, base + OTG_CFG, OTG_EN_SRC_CFG, 0);
+
+   return 0;
+}
+
+static const struct of_device_id qcom_usb_vbus_regulator_match[] = {
+   { .compatible = "qcom,pm8150b-vbus-reg" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, qcom_usb_vbus_regulator_match);
+
+static struct platform_driver qcom_usb_vbus_regulator_driver = {
+   .driver = {
+

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

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

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

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 322379d5c31f..91b870345dda 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,13 @@ power-on@800 {
status = "disabled";
};
 
+   pm8150b_typec: typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   status = "disabled";
+   reg = <0x1500>;
+   interrupts = <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 5/6] dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator

This describes how to enable the Qualcomm PMIC VBUS booster used for
providing power to connected USB peripherals when the USB role is host
mode.  The driver itself will register the vbus_usb regulator, so that
external drivers can utilize the enable/disable regulator APIs.

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

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
new file mode 100644
index ..12ed98c28aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Qualcomm PMIC VBUS output regulator driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  This regulator driver controls the VBUS output by the Qualcomm PMIC.  This
+  regulator will be enabled in situations where the device is required to
+  provide power to the connected peripheral.
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-vbus-reg
+
+  reg:
+maxItems: 1
+description: VBUS output base address
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+ pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+pm8150b_vbus: dcdc@1100 {
+compatible = "qcom,pm8150b-vbus-reg";
+reg = <0x1100>;
+};
+ };
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

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

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

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

[PATCH v4 1/6] usb: typec: Add QCOM PMIC typec detection driver

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

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

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

Re: I need to study Python

2020-06-26 Thread Wesley Peng


Pick a book like Core Python Programming, read it and do coding follow it.

regards.

sinanp...@gmail.com wrote:

Hey, I'm a completely noob.
I want to learn python, how can i or where can i study python?


--
https://mail.python.org/mailman/listinfo/python-list

[PATCH v3 2/2] phy: qcom-snps: Add a set mode callback

The set mode handler is used to keep track of the current role of the
device.  This is used for enabling certain resources within the PHY
depending on if the device is behaving as a host or device.

Signed-off-by: Wesley Cheng 
---
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c 
b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index 152d8633f4ea..ae4bac024c7b 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -77,6 +77,7 @@ static const char * const qcom_snps_hsphy_vreg_names[] = {
  * @phy_reset: phy reset control
  * @vregs: regulator supplies bulk data
  * @phy_initialized: if PHY has been initialized correctly
+ * @mode: contains the current mode the PHY is in
  */
 struct qcom_snps_hsphy {
struct phy *phy;
@@ -88,6 +89,7 @@ struct qcom_snps_hsphy {
struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS];
 
bool phy_initialized;
+   enum phy_mode mode;
 };
 
 static inline void qcom_snps_hsphy_write_mask(void __iomem *base, u32 offset,
@@ -161,6 +163,15 @@ static int __maybe_unused 
qcom_snps_hsphy_runtime_resume(struct device *dev)
return 0;
 }
 
+static int qcom_snps_hsphy_set_mode(struct phy *phy, enum phy_mode mode,
+   int submode)
+{
+   struct qcom_snps_hsphy *hsphy = phy_get_drvdata(phy);
+
+   hsphy->mode = mode;
+   return 0;
+}
+
 static int qcom_snps_hsphy_init(struct phy *phy)
 {
struct qcom_snps_hsphy *hsphy = phy_get_drvdata(phy);
@@ -258,6 +269,7 @@ static int qcom_snps_hsphy_exit(struct phy *phy)
 static const struct phy_ops qcom_snps_hsphy_gen_ops = {
.init   = qcom_snps_hsphy_init,
.exit   = qcom_snps_hsphy_exit,
+   .set_mode   = qcom_snps_hsphy_set_mode,
.owner  = THIS_MODULE,
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 1/2] phy: qcom-snps: Add runtime suspend and resume handlers

Allow for the PHY to be put into a powered down state when possible.
Add the required suspend and resume callbacks, which will determine
what resources can be turned off depending on the cable status.

Signed-off-by: Wesley Cheng 
Reviewed-by: Vinod Koul 
---
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 73 +++
 1 file changed, 73 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c 
b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index 4d74045271eb..152d8633f4ea 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -104,6 +104,63 @@ static inline void qcom_snps_hsphy_write_mask(void __iomem 
*base, u32 offset,
readl_relaxed(base + offset);
 }
 
+static int qcom_snps_hsphy_suspend(struct qcom_snps_hsphy *hsphy)
+{
+   dev_dbg(>phy->dev, "Suspend QCOM SNPS PHY\n");
+
+   if (hsphy->mode == PHY_MODE_USB_HOST) {
+   /* Enable auto-resume to meet remote wakeup timing */
+   qcom_snps_hsphy_write_mask(hsphy->base,
+  USB2_PHY_USB_PHY_HS_PHY_CTRL2,
+  USB2_AUTO_RESUME,
+  USB2_AUTO_RESUME);
+   usleep_range(500, 1000);
+   qcom_snps_hsphy_write_mask(hsphy->base,
+  USB2_PHY_USB_PHY_HS_PHY_CTRL2,
+  0, USB2_AUTO_RESUME);
+   }
+
+   clk_disable_unprepare(hsphy->cfg_ahb_clk);
+   return 0;
+}
+
+static int qcom_snps_hsphy_resume(struct qcom_snps_hsphy *hsphy)
+{
+   int ret;
+
+   dev_dbg(>phy->dev, "Resume QCOM SNPS PHY, mode\n");
+
+   ret = clk_prepare_enable(hsphy->cfg_ahb_clk);
+   if (ret) {
+   dev_err(>phy->dev, "failed to enable cfg ahb clock\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static int __maybe_unused qcom_snps_hsphy_runtime_suspend(struct device *dev)
+{
+   struct qcom_snps_hsphy *hsphy = dev_get_drvdata(dev);
+
+   if (!hsphy->phy_initialized)
+   return 0;
+
+   qcom_snps_hsphy_suspend(hsphy);
+   return 0;
+}
+
+static int __maybe_unused qcom_snps_hsphy_runtime_resume(struct device *dev)
+{
+   struct qcom_snps_hsphy *hsphy = dev_get_drvdata(dev);
+
+   if (!hsphy->phy_initialized)
+   return 0;
+
+   qcom_snps_hsphy_resume(hsphy);
+   return 0;
+}
+
 static int qcom_snps_hsphy_init(struct phy *phy)
 {
struct qcom_snps_hsphy *hsphy = phy_get_drvdata(phy);
@@ -212,6 +269,11 @@ static const struct of_device_id 
qcom_snps_hsphy_of_match_table[] = {
 };
 MODULE_DEVICE_TABLE(of, qcom_snps_hsphy_of_match_table);
 
+static const struct dev_pm_ops qcom_snps_hsphy_pm_ops = {
+   SET_RUNTIME_PM_OPS(qcom_snps_hsphy_runtime_suspend,
+  qcom_snps_hsphy_runtime_resume, NULL)
+};
+
 static int qcom_snps_hsphy_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -255,6 +317,14 @@ static int qcom_snps_hsphy_probe(struct platform_device 
*pdev)
return ret;
}
 
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+   /*
+* Prevent runtime pm from being ON by default. Users can enable
+* it using power/control in sysfs.
+*/
+   pm_runtime_forbid(dev);
+
generic_phy = devm_phy_create(dev, NULL, _snps_hsphy_gen_ops);
if (IS_ERR(generic_phy)) {
ret = PTR_ERR(generic_phy);
@@ -269,6 +339,8 @@ static int qcom_snps_hsphy_probe(struct platform_device 
*pdev)
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
if (!IS_ERR(phy_provider))
dev_dbg(dev, "Registered Qcom-SNPS HS phy\n");
+   else
+   pm_runtime_disable(dev);
 
return PTR_ERR_OR_ZERO(phy_provider);
 }
@@ -277,6 +349,7 @@ static struct platform_driver qcom_snps_hsphy_driver = {
.probe  = qcom_snps_hsphy_probe,
.driver = {
.name   = "qcom-snps-hs-femto-v2-phy",
+   .pm = _snps_hsphy_pm_ops,
.of_match_table = qcom_snps_hsphy_of_match_table,
},
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 0/2] phy: qcom-snps: Add runtime suspend and resume handlers

Changes in v3:
 - Fixed strict checkpatch warnings due to alignment
 - Remove debug artifacts from prints
 - Split the set mode callback addition to another patch
 - Removed suspended parameter

Changes in v2:
 - Addressed checkpatch alignment/line length warnings.
 - Removed superfluous init in qcom_snps_hsphy_resume().

Adds a set mode callback and runtime suspend/resume handlers to the
phy-qcom-snps-femto-v2 driver.  The set mode is used to enable certain
power management features in the PHY during suspend/resume.

Wesley Cheng (2):
  phy: qcom-snps: Add runtime suspend and resume handlers
  phy: qcom-snps: Add a set mode callback

 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 85 +++
 1 file changed, 85 insertions(+)

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

Re: [PATCH v2] phy: qcom-snps: Add runtime suspend and resume handlers




On 6/24/2020 5:21 AM, Vinod Koul wrote:
> Hi Wesley,
> 
> On 21-05-20, 18:50, Wesley Cheng wrote:
>> Allow for the PHY to be put into a powered down state when possible.
>> Add the required suspend and resume callbacks, which will determine
>> what resources can be turned off depending on the cable status.
>>
>> Signed-off-by: Wesley Cheng 
>>
>> ---
>> Changes in v2:
>>  - Addressed checkpatch alignment/line length warnings.
>>  - Removed superfluous init in qcom_snps_hsphy_resume().
>>
>>  drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 100 
>> ++
>>  1 file changed, 100 insertions(+)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c 
>> b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
>> index 4d74045..0a4e77af 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
>> @@ -76,7 +76,9 @@
>>   * @iface_clk: phy interface clock
>>   * @phy_reset: phy reset control
>>   * @vregs: regulator supplies bulk data
>> + * @suspended: PHY is in the suspended state
>>   * @phy_initialized: if PHY has been initialized correctly
>> + * @mode: contains the current mode the PHY is in
>>   */
>>  struct qcom_snps_hsphy {
>>  struct phy *phy;
>> @@ -87,7 +89,9 @@ struct qcom_snps_hsphy {
>>  struct reset_control *phy_reset;
>>  struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS];
>>  
>> +bool suspended;
>>  bool phy_initialized;
>> +enum phy_mode mode;
>>  };
>>  
>>  static inline void qcom_snps_hsphy_write_mask(void __iomem *base, u32 
>> offset,
>> @@ -104,6 +108,84 @@ static inline void qcom_snps_hsphy_write_mask(void 
>> __iomem *base, u32 offset,
>>  readl_relaxed(base + offset);
>>  }
>>  
>> +static int qcom_snps_hsphy_suspend(struct qcom_snps_hsphy *hsphy)
>> +{
>> +if (hsphy->suspended)
>> +return 0;
> 
> Am still not convinced why this would be called when we are already
> suspended :)
> 

Hi Vinod,

OK, we can remove it for now, and if its really required further on, we
can re-add.

>> +
>> +dev_dbg(>phy->dev, "Suspend QCOM SNPS PHY, mode:%d\n",
>> +hsphy->mode);
> 
> Remove debug artifacts here?
> 

Sure, can do that.

>> +
>> +if (hsphy->mode == PHY_MODE_USB_HOST) {
>> +/* Enable auto-resume to meet remote wakeup timing */
>> +qcom_snps_hsphy_write_mask(hsphy->base,
>> +USB2_PHY_USB_PHY_HS_PHY_CTRL2,
>> +USB2_AUTO_RESUME,
>> +USB2_AUTO_RESUME);
> 
> Lets align the lines above to opening brace please..
> If you run checkpatch with --strict option you would get this CHECK: 
> Alignment should match open parenthesis
> 

OK, got it.  Fixed a few other spacing warnings as well.

>> +usleep_range(500, 1000);
>> +qcom_snps_hsphy_write_mask(hsphy->base,
>> +USB2_PHY_USB_PHY_HS_PHY_CTRL2,
>> +0, USB2_AUTO_RESUME);
>> +}
>> +
>> +clk_disable_unprepare(hsphy->cfg_ahb_clk);
>> +hsphy->suspended = true;
>> +
>> +return 0;
>> +}
>> +
>> +static int qcom_snps_hsphy_resume(struct qcom_snps_hsphy *hsphy)
>> +{
>> +int ret;
>> +
>> +if (!hsphy->suspended)
>> +return 0;
>> +
>> +dev_dbg(>phy->dev, "Resume QCOM SNPS PHY, mode:%d\n",
>> +hsphy->mode);
> 
> here as well
> 

Done.

>> +
>> +ret = clk_prepare_enable(hsphy->cfg_ahb_clk);
>> +if (ret) {
>> +dev_err(>phy->dev,
>> +"failed to enable cfg ahb clock, %d\n", ret);
> 
> single line should be okay now :)
> 

Yep!

>> +return ret;
>> +}
>> +
>> +hsphy->suspended = false;
>> +return 0;
>> +}
>> +
>> +static int __maybe_unused qcom_snps_hsphy_runtime_suspend(struct device 
>> *dev)
>> +{
>> +struct qcom_snps_hsphy *hsphy = dev_get_drvdata(dev);
>> +
>> +if (!hsphy->phy_initialized)
>> +return 0;
>> +
>> +qcom_snps_hsphy_suspend(hsphy);
>> +return 0;
>> +}
>> +
>> +static int __maybe_unused qcom_snps_hsphy_runtime_resume(struct device *d

Re: NiFi 1.11 - High repository storage usage

2020-06-25 Thread Wesley C. Dias de Oliveira

Hi, Valentina.

I've experienced the same issue on an old installation.

In my case, it was related to memory usage.

The system begins to dump things to the disk when there's no available
memory.

Have you checked the memory( params?

# JVM memory settings
java.arg.2=-Xms512m
java.arg.3=-Xmx512m






Em qui., 25 de jun. de 2020 às 09:50, Valentina Ivanova <
valentina.ivan...@ri.se> escreveu:

> Hello!
>
> I see (screenshot attached) quite high (86%) storage usage for all three
> Flow File, Content & Provenance Repositories in the System Diagnostics.
> When I check the size of the respective folders on the disk they don't even
> add up to 12,24 GB shown on the screenshot.
> I also have the following settings for the content repository in
> nifi.properties:
> nifi.content.repository.archive.max.retention.period=12 hours
> nifi.content.repository.archive.max.usage.percentage=50%
> nifi.content.repository.archive.enabled=true
> nifi.content.repository.always.sync=false
>
>
> So I am wondering where these numbers are coming from and how to reduce
> the storage utilization (I assume such high utilization will impact the
> performance)? Why is the content repository usage 86% even though the
> max.usage.percentage is set at 50%.
>
> Many thanks in advance & all the best
>
> Valentina
>
>
>
>

-- 
Grato,
Wesley C. Dias de Oliveira.

Linux User nº 576838.

[Mpi-forum] Meeting Registration Reminder and Voting Guidelines

2020-06-24 Thread Wesley Bland via mpi-forum

Action Items:

1. Register for the meeting next week if you haven’t already.
2. Confirm that you are able to use the voting link and arrange who will vote 
from your org.

===

Hi all,

I just wanted to send out one final reminder for people to register for next 
week’s MPI Forum meeting. There are still a few orgs who usually attend but 
have not registered.

https://forms.gle/65bMTDiUQBmbJgjs9  

The MPI Forum procedures state that you must both register and attend the 
meeting before the first voting block in order to be officially counted and to 
be eligible to vote. The first voting block is Tuesday at 9:30 AM Central US so 
that means you will need to have attended at least some portion of the Monday 
meeting and/or the very beginning of the Tuesday meeting in order to be 
eligible to vote in either voting block at the meeting.

If you’re not sure if you’ve registered, you can find the list of people here:

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

We will also be using the same voting system as from the last exceptional 
virtual meeting in May (JotForm). My understanding is that you will need to 
enable Javascript in your browser in order for this to work. If you’d like to 
double check that the voting page will work for you this time, you can use the 
voting page from last time using this link:

https://form.jotform.com/201253678123047?participantId=a1b2c3d4=Test_Name=Test_Org
 


When the voting block opens, I’ll be sending an automated email to the address 
you used to register with a personalized link for your ballot. If you didn’t 
provide an email address (I forgot to add an email address to the original 
registration form), I’ll be using the one you’ve usually been using for the MPI 
Forum. If you want to change the email address that I use, email me directly 
and let me know.

Remember that each organization only gets one vote (not one per person). So for 
those organizations with more than one representative, please make arrangements 
ahead of time to determine who will be casting the ballot for your 
organization. If I get more than one ballot from an organization, I will 
discard all but one of them (probably the first, maybe the last).

As always, if you have any questions or comments or think I’ve made any 
mistakes, please let me know on email or Slack.

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

[RFC v4 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

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.

Ensure that one TX FIFO is reserved for every IN endpoint.  This allows for
the FIFO logic to prevent running out of FIFO space.

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

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index edc17155cb2b..cca555493929 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1304,6 +1304,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 4c171a8e215f..ce0bf288b6ac 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -675,6 +675,7 @@ struct dwc3_event_buffer {
  * isochronous START TRANSFER command failure workaround
  * @start_cmd_status: the status of testing START TRANSFER command with
  * combo_num = 'b00
+ * @fifo_depth: allocated TXFIFO depth
  */
 struct dwc3_ep {
struct usb_ep   endpoint;
@@ -727,6 +728,7 @@ struct dwc3_ep {
/* For isochronous START TRANSFER workaround only */
u8  combo_num;
int start_cmd_status;
+   int fifo_depth;
 };
 
 enum dwc3_phy {
@@ -1004,6 +1006,7 @@ struct dwc3_scratchpad_array {
  * 1   - utmi_l1_suspend_n
  * @is_fpga: true when we are using the FPGA board
  * @pending_events: true when we have pending IRQs to be handled
+ * @needs_fifo_resize: not all users might want fifo resizing, flag it
  * @pullups_connected: true when Run/Stop bit is set
  * @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
  * @three_stage_setup: set if we perform a three phase setup
@@ -1044,6 +1047,8 @@ struct dwc3_scratchpad_array {
  * @dis_metastability_quirk: set to disable metastability quirk.
  * @imod_interval: set the interrupt moderation interval in 250ns
  * increments or 0 to disable.
+ * @last_fifo_depth: total TXFIFO depth of all enabled USB IN/INT endpoints
+ * @num_ep_resized: the number of TX FIFOs that have already been resized
  */
 struct dwc3 {
struct work_struct  drd_work;
@@ -1204,6 +1209,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;
@@ -1236,6 +1242,8 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
 
u16 imod_interval;
+   int last_fifo_depth;
+   int num_ep_resized;
 };
 
 #define INCRX_BURST_MODE 0
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 6dee4dabc0a4..76db9b530861 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -601,8 +601,9 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
 {
enum usb_device_state state = dwc->gadget.state;
u32 cfg;
-   int ret;
+   int ret, num, size;
u32 reg;
+   struct dwc3_ep *dep;
 
cfg = le16_to_cpu(ctrl->wValue);
 
@@ -611,6 +612,40 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
return -EINVAL;
 
case USB_STATE_ADDRESS:
+   /*
+* If tx-fifo-resize flag is not set for the controller, then
+* do not clear existing allocated TXFIFO since we do not
+* allocate it again in dwc3_gadget_resize_tx_fifos
+*/
+   if (dwc->needs_fifo_resize) {
+   /* Read ep0IN related TXFIFO size */
+   dep = dwc->eps[1];
+   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ

[RFC v4 3/3] dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

Re-introduce the comment for the tx-fifo-resize setting for the DWC3
controller.  This allows for vendors to control if they require the TX FIFO
resizing logic on their HW, as the default FIFO size configurations may
already be sufficient.

Signed-off-by: Wesley Cheng 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 9946ff9ba735..489f5da83744 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -105,7 +105,7 @@ Optional properties:
1-16 (DWC_usb31 programming guide section 1.2.3) to
enable periodic ESS TX threshold.
 
- -  tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
  - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
register, undefined length INCR burst type enable and 
INCRx type.
When just one value, which means INCRX burst mode 
enabled. When
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC v4 0/3] Re-introduce TX FIFO resize for larger EP bursting

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 (3):
  usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
  arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic
  dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

 .../devicetree/bindings/usb/dwc3.txt  |   2 +-
 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|  37 +-
 drivers/usb/dwc3/gadget.c | 115 ++
 6 files changed, 163 insertions(+), 2 deletions(-)

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

[RFC v4 2/3] arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic

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 a36512d1f6a1..c28523313955 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -708,6 +708,7 @@ usb_1_dwc3: dwc3@a60 {
interrupts = ;
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: Symbol.await proposal

2020-06-22 Thread Wesley Oliver

> Hi,
>
> That doesn't work, kinda work in javascript world where the function has
> finite, fixed set of arguments, were there is a definition of last one.
> Typescript helps a lot with that, because
> it can ensure to a higher degree, that types are correct, js on its own,
> loose so you have less guarantees of the binding.
> Just have to assume that every function has like a callback by convention,
> if it doesn't then break things again.
> Typescript does help.
>
> function anyArguments(callback) {
>  let args = [...arguments];
> // args.length > 99 and callback is the 1st parameters.
> }
>
> You can check out this is want project setup, that allow us to peace meal
> upgrade to ts.
> https://github.com/wesleyolis/configFactoryLoaderAndValidator
> Few additional pointers:
> type AnyJS = any; / this allow you keep track of intentional usage, so
> search codebase later.
>  If you have old library with no types, then basically import the new
> library with types under a different alias name,
> then have both old and new versions and peace meal upgrade as required.
>
> Kind Regards,
>
> Wesley Oliver
>
>
>
> On Mon, Jun 22, 2020 at 10:13 PM Jamie  wrote:
>
>> One of the common refactorings I do is:
>>
>> let file1 = await readFile(filename1)
>> let file2 = await readFile(filename2)
>> // to
>> let [file1, file2] = await Promise.all([
>>   readFile(filename1),
>>   readFile(filename2),
>> ])
>>
>> I would be very confused if refactoring it in this way made my code break
>> because of some implicit behavior around `await` specifically.
>>
>> I have seen some APIs that switch to promises when a callback argument is
>> not provided. Is this not a sufficient solution?
>>
>> On Mon, Jun 22, 2020 at 12:22 PM James M Snell  wrote:
>>
>>> For many legacy code bases that are based on callbacks mechanisms like
>>> node.js' promisify function are required to help facilitate the transition
>>> from callback centric code to Promise-centric. A lot of the time, these can
>>> follow straightforward rules without requiring customization. However, at
>>> other times it is necessary for user code to provide custom implementations
>>> of the Promise-version of the function.
>>>
>>> In Node.js, we accomplish this by allowing a function to have a symbol
>>> attached whose value is an alternative function that is returned by the
>>> promisify function
>>>
>>> For instance,
>>>
>>>   function myFunction(foo, bar, callback) {
>>> callback(null, foo, bar);
>>>   }
>>>   myFunction[util.customPromisifySymbol] = async function(foo, bar) {
>>> return [foo, bar];
>>>   }
>>>
>>>   const { promisify } = require('util');
>>>   const mine = promisify(myFunction);
>>>   (async () => console.log(await mine('a','b')))();
>>>
>>> As a convenience built into the language, it would be nice to be able to
>>> short-circuit the need to call promisify with a special language-level
>>> Symbol used specifically for this purpose:
>>>
>>>   function myFunction(foo, bar, callback) {
>>> callback(null, foo, bar);
>>>   }
>>>   myFunction[Symbol.await] = async function(foo, bar) {
>>> return [foo, bar];
>>>   }
>>>
>>>   (async () => console.log(await myFunction('a','b')))();
>>>
>>> The idea here is that if the function being awaited has the
>>> [Symbol.await] property whose value is a function, then that function is
>>> called when the await keyword is used. That is,
>>>
>>>   myFunction('a', 'b', callback); // Invokes myFunction directly
>>>   await myFunction('a', 'b');  // Invokes myFunction[Symbol.await]
>>>
>>> if the Symbol.await property is not set or is not callable, then it
>>> would fallback to default behavior.
>>>
>>> Automatic handling of this binding should also happen but has some
>>> technical detail to work out:
>>>
>>>   const obj = {
>>> a: 1,
>>> foo() {}
>>>   };
>>>   obj.foo[Symbol.await] = async function() {
>>> return this.a;
>>>   }
>>>   await obj.foo();  // Calls await obj.foo[Symbol.await] with bound this
>>>
>>> This approach would make it far easier for legacy code bases to make the
>>> transition to async/await syntax while maintaining legacy compat.
>>>
>>> Before writing up a formal proposal, I wanted to solicit some fe

Re: Symbol.await proposal

2020-06-22 Thread Wesley Oliver

Hi,

The one interesting case you have to look at dealing with, is the one I
came across where by the call of a function can return a results and will
then later async call the callback in the future.
Because with the proposal above, you have lost the ability to, return the
return result and callback results you have return {execReturn:...,
awaitResult:}, this doesn't happen offen.

I think one approach that you could take but wouldn't always work, check
for additional the call back parameter, then either return Promisification
or you do the call back execution.
a wrapper would help with that.

The other could also look at a special import syntax for modules, whereby
methods are automatically promisified, with this wrap approach or shallow
copy.

The problem is that for a function that can accept in javascript any number
of parameters, arguments, were is no finite number of arguments,  you can't
be certain that there is a callback or if the last parameter
is indeed a param. One could do type check on the last parameter, otherwise
you have a naming convention for functions, to avoid the confusion,
provided you could check the key(name)
Promise all suffers the same problem with the last parameter, it is a
convention.

Kind Regards,

Wesley Oliver

On Mon, Jun 22, 2020 at 9:21 PM James M Snell  wrote:

> For many legacy code bases that are based on callbacks mechanisms like
> node.js' promisify function are required to help facilitate the transition
> from callback centric code to Promise-centric. A lot of the time, these can
> follow straightforward rules without requiring customization. However, at
> other times it is necessary for user code to provide custom implementations
> of the Promise-version of the function.
>
> In Node.js, we accomplish this by allowing a function to have a symbol
> attached whose value is an alternative function that is returned by the
> promisify function
>
> For instance,
>
>   function myFunction(foo, bar, callback) {
> callback(null, foo, bar);
>   }
>   myFunction[util.customPromisifySymbol] = async function(foo, bar) {
> return [foo, bar];
>   }
>
>   const { promisify } = require('util');
>   const mine = promisify(myFunction);
>   (async () => console.log(await mine('a','b')))();
>
> As a convenience built into the language, it would be nice to be able to
> short-circuit the need to call promisify with a special language-level
> Symbol used specifically for this purpose:
>
>   function myFunction(foo, bar, callback) {
> callback(null, foo, bar);
>   }
>   myFunction[Symbol.await] = async function(foo, bar) {
> return [foo, bar];
>   }
>
>   (async () => console.log(await myFunction('a','b')))();
>
> The idea here is that if the function being awaited has the [Symbol.await]
> property whose value is a function, then that function is called when the
> await keyword is used. That is,
>
>   myFunction('a', 'b', callback); // Invokes myFunction directly
>   await myFunction('a', 'b');  // Invokes myFunction[Symbol.await]
>
> if the Symbol.await property is not set or is not callable, then it would
> fallback to default behavior.
>
> Automatic handling of this binding should also happen but has some
> technical detail to work out:
>
>   const obj = {
> a: 1,
> foo() {}
>   };
>   obj.foo[Symbol.await] = async function() {
> return this.a;
>   }
>   await obj.foo();  // Calls await obj.foo[Symbol.await] with bound this
>
> This approach would make it far easier for legacy code bases to make the
> transition to async/await syntax while maintaining legacy compat.
>
> Before writing up a formal proposal, I wanted to solicit some feedback on
> this approach to see what folks thought.
>
> - James
> _______
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

-- 

GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbol.await proposal

2020-06-22 Thread Wesley Oliver

> const promise = Promisify(object, 'method');const results = await 
> promise(param1, param2, param3, param3);
>
>
> <https://github.com/wesleyolis/BlueBirdObjectOrientatedPromisification#promises-return-type-can-also-be-overloaded>Promises
> Return type can also be overloaded
>
> Requires spesifying both Promise Return type and callback method type.
>
> const promise = Promisify<{results : ''},(() => void)>(method);
>
>
> <https://github.com/wesleyolis/BlueBirdObjectOrientatedPromisification#promise-with-returntype-some-weird-libaries>Promise
> with ReturnType, some weird libaries.
>
> const promise = PromisifyReturn(...);let returnType = 
> {}promise(,returnType);
> console.log(returnType['executeResult']);
>
>
> On Mon, Jun 22, 2020 at 9:21 PM James M Snell  wrote:
>
>> For many legacy code bases that are based on callbacks mechanisms like
>> node.js' promisify function are required to help facilitate the transition
>> from callback centric code to Promise-centric. A lot of the time, these can
>> follow straightforward rules without requiring customization. However, at
>> other times it is necessary for user code to provide custom implementations
>> of the Promise-version of the function.
>>
>> In Node.js, we accomplish this by allowing a function to have a symbol
>> attached whose value is an alternative function that is returned by the
>> promisify function
>>
>> For instance,
>>
>>   function myFunction(foo, bar, callback) {
>> callback(null, foo, bar);
>>   }
>>   myFunction[util.customPromisifySymbol] = async function(foo, bar) {
>> return [foo, bar];
>>   }
>>
>>   const { promisify } = require('util');
>>   const mine = promisify(myFunction);
>>   (async () => console.log(await mine('a','b')))();
>>
>> As a convenience built into the language, it would be nice to be able to
>> short-circuit the need to call promisify with a special language-level
>> Symbol used specifically for this purpose:
>>
>>   function myFunction(foo, bar, callback) {
>> callback(null, foo, bar);
>>   }
>>   myFunction[Symbol.await] = async function(foo, bar) {
>> return [foo, bar];
>>   }
>>
>>   (async () => console.log(await myFunction('a','b')))();
>>
>> The idea here is that if the function being awaited has the
>> [Symbol.await] property whose value is a function, then that function is
>> called when the await keyword is used. That is,
>>
>>   myFunction('a', 'b', callback); // Invokes myFunction directly
>>   await myFunction('a', 'b');  // Invokes myFunction[Symbol.await]
>>
>> if the Symbol.await property is not set or is not callable, then it would
>> fallback to default behavior.
>>
>> Automatic handling of this binding should also happen but has some
>> technical detail to work out:
>>
>>   const obj = {
>> a: 1,
>> foo() {}
>>   };
>>   obj.foo[Symbol.await] = async function() {
>> return this.a;
>>   }
>>   await obj.foo();  // Calls await obj.foo[Symbol.await] with bound this
>>
>> This approach would make it far easier for legacy code bases to make the
>> transition to async/await syntax while maintaining legacy compat.
>>
>> Before writing up a formal proposal, I wanted to solicit some feedback on
>> this approach to see what folks thought.
>>
>> - James
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> --
> 
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.o...@gmail.com
>


-- 

GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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

2020-06-22 Thread Wesley Cheng




On 6/18/2020 3:23 PM, Rob Herring wrote:
> On Thu, Jun 18, 2020 at 2:09 PM Wesley Cheng  wrote:
>>
>>
>> On 6/18/2020 11:33 AM, Rob Herring wrote:
>>> On Wed, Jun 17, 2020 at 12:02 PM Wesley Cheng  wrote:
>>>
>>> You are duplicating everything in usb-connector.yaml. You should have
>>> a $ref to it.
>>>
>>
>> Hi Rob,
>>
>> Sure, I will add a reference to that doc.
>>
>>>
>>> This is wrong. The connector binding says port 0 is the connection the
>>> USB HS controller.
>>>
>>> What's a type C mux node? Is there a binding for that? There's an
>>> ongoing discussion with the CrOS folks on how to describe Alt mode
>>> mux/switches.
>>
>> I reviewed the connector binding previously, and couldn't seem to come
>> up with a model which fit a design where the type C controller (ie the
>> entity which does the CC orientation and role detection) does not have
>> the SS lane mux included.  The SS lane mux is the HW which handles the
>> selection of the SS lanes to utilize based on cable orientation.
> 
> The intent was the controller would be the parent node of the connector.
> 

Hi Rob,

Correct, I agree with that point, and in the changes uploaded, the QCOM
PMIC type C controller will be the parent node for the connector.

> How the SS lane mux is represented is what needs to be figured out. I
> don't know what that looks like, but it needs to be something that
> works for multiple designs. Ideally, that's an extension of the
> existing 'usb-c-connector' binding, but if there's good reasons to
> redesign it that can happen.
> 
> Rob
> 

We probably wouldn't need to redesign it, but maybe if we can remove the
connector port assignments requirement, it would allow for some
flexibility.  From my knowledge, I don't think any driver is actually
utilizing or checking the port number assignments, so there isn't a
limitation on what could be defined in there.

Here's a simplified diagram of the FUSB302 reference design from the
data sheet.  The I2C bus is just for CSR access to the FUSB302.

   ___   ___
__|FUSB302| |SOC|
   |  |Type C | |   |
   |  |Cntrl  |__I2C___ |   |
   |  |___| |   |
 ___   ||   |
|   |__ CC1/2 _||   |
|   |__ HS DP/DM __ |   |
|   |   |   |
    |   |
|   |__ SS RX/TX1 |FUSB304 |__SS RX/TX_ |   |
|   |__ SS RX/TX2 |USB Mux ||___|
|   | ||
|   |
|___|


Otherwise, we can just simply add another port definition for external
SS lane muxes if possible.

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

Re: GridIoManager compile error(2.8.0)

2020-06-21 Thread Wesley





38797715 wrote:
I downloaded the source code of version 2.8.1, but found that it could 
not be compiled successfully, and there were compilation errors in the 
code.


We just use the binary package, won't compile that by ourselves. :)

regards

Re: Unsubscribe

2020-06-21 Thread Wesley


please send an empty email to:
dev-unsubscr...@spark.apache.org
user-unsubscr...@spark.apache.org

for unsubscribing yourself from the lists.

Thanks.


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

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

2020-06-18 Thread Wesley Cheng

On 6/18/2020 11:33 AM, Rob Herring wrote:
> On Wed, Jun 17, 2020 at 12:02 PM Wesley Cheng  wrote:
> 
> You are duplicating everything in usb-connector.yaml. You should have
> a $ref to it.
> 

Hi Rob,

Sure, I will add a reference to that doc.

> 
> This is wrong. The connector binding says port 0 is the connection the
> USB HS controller.
> 
> What's a type C mux node? Is there a binding for that? There's an
> ongoing discussion with the CrOS folks on how to describe Alt mode
> mux/switches.

I reviewed the connector binding previously, and couldn't seem to come
up with a model which fit a design where the type C controller (ie the
entity which does the CC orientation and role detection) does not have
the SS lane mux included.  The SS lane mux is the HW which handles the
selection of the SS lanes to utilize based on cable orientation.

I looked at the FUSB302 TCPM driver, which doesn't have an integrated SS
lane mux, and relies on an external FUSB340 switch to handle the
polarity, but seems that in the fusb302.c driver it doesn't implement
the polarity handler.  They might possibly have a HW output signal which
controls the mux directly, but I'm not sure on that.

Anyway, if someone wanted to take a SW approach and program an external
mux, this model doesn't seem to allow that.  This is somewhat unrelated
to the DP AUX mode switching, as that probably will only come into the
picture after the policy engine has detected there is a DP adapter
connected, whereas this is applicable to non DP/alt mode situations.

Thanks!

>> +type: object
>> +
>> +properties:
>> +  remote-endpoint:
>> +maxItems: 1
>> +description: Node reference to the type C mux
>> +
>> +  endpoint@1:
>> +description: Connection to role switch node
> 
> Again, what's this?
> 

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

Re:

2020-06-18 Thread Wesley

Please send an empty email to: user-unsubscr...@hive.apache.org for 
unsubscribing yourself. Thanks.




user-unsubscribe

[PATCH v3 5/6] dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator

This describes how to enable the Qualcomm PMIC VBUS booster used for
providing power to connected USB peripherals when the USB role is host
mode.  The driver itself will register the vbus_usb regulator, so that
external drivers can utilize the enable/disable regulator APIs.

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

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
new file mode 100644
index ..2fa76111cfb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Qualcomm PMIC VBUS output regulator driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  This regulator driver controls the VBUS output by the Qualcomm PMIC.  This
+  regulator will be enabled in situations where the device is required to
+  provide power to the connected peripheral.
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-vbus-reg
+
+  reg:
+maxItems: 1
+description: VBUS output base address
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+ pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,dcdc@1100 {
+compatible = "qcom,pm8150b-vbus-reg";
+reg = <0x1100>;
+};
+ };
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 0/6] Introduce PMIC based USB type C detection

Changes in v3:
 - Fix driver reference to match driver name in Kconfig for
   qcom_usb_vbus-regulator.c
 - Utilize regulator bitmap helpers for enable, disable and is enabled calls in
   qcom_usb_vbus-regulator.c
 - Use of_get_regulator_init_data() to initialize regulator init data, and to
   set constraints in qcom_usb_vbus-regulator.c
 - Remove the need for a local device structure in the vbus regulator driver
 
Changes in v2:
 - Use devm_kzalloc() in qcom_pmic_typec_probe()
 - Add checks to make sure return value of typec_find_port_power_role() is
   valid
 - Added a VBUS output regulator driver, which will be used by the PMIC USB
   type c driver to enable/disable the source
 - Added logic to control vbus source from the PMIC type c driver when
   UFP/DFP is detected
 - Added dt-binding for this new regulator driver
 - Fixed Kconfig typec notation to match others
 - Leave type C block disabled until enabled by a platform DTS

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

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

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

 .../regulator/qcom,usb-vbus-regulator.yaml|  41 +++
 .../bindings/usb/qcom,pmic-typec.yaml | 117 
 arch/arm64/boot/dts/qcom/pm8150b.dtsi |  14 +
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts   |   7 +
 drivers/regulator/Kconfig |  10 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c   | 100 +++
 drivers/usb/typec/Kconfig |  12 +
 drivers/usb/typec/Makefile|   1 +
 drivers/usb/typec/qcom-pmic-typec.c   | 275 ++
 10 files changed, 578 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

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

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

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

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

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index ec44a8bc2f84..b7274d9d7341 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,12 @@ power-on@800 {
status = "disabled";
};
 
+   qcom,dcdc@1100 {
+   compatible = "qcom,pm8150b-vbus-reg";
+   status = "disabled";
+   reg = <0x1100>;
+   };
+
qcom,typec@1500 {
compatible = "qcom,pm8150b-usb-typec";
status = "disabled";
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts 
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6c6325c3af59..3845d19893eb 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -426,6 +426,13 @@ _1 {
status = "okay";
 };
 
+_bus {
+   pmic@2 {
+   qcom,dcdc@1100 {
+   status = "okay";
+   };
+};
+
 _1_dwc3 {
dr_mode = "peripheral";
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

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

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

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 322379d5c31f..ec44a8bc2f84 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,14 @@ power-on@800 {
status = "disabled";
};
 
+   qcom,typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   status = "disabled";
+   reg = <0x1500>;
+   interrupts =
+   <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

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

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

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

[PATCH v3 1/6] usb: typec: Add QCOM PMIC typec detection driver

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

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

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

[PATCH v3 4/6] regulator: Add support for QCOM PMIC VBUS booster