Re: [PATCH v2 3/3] usb: chipidea: imx: set over current polarity per dts setting
On Wed, Jul 20, 2016 at 04:02:42PM +0800, Li Jun wrote:
> imx usb over current polarity is low active by default, with
> over-current-active-high property added, user can config it to be high
> active. Meanwhile keep this setting unchanged for existing platforms
> so new platform must set the right value for active low by its usbmisc
> init function if over current is enabled.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 3 +++
> drivers/usb/chipidea/ci_hdrc_imx.h | 1 +
> drivers/usb/chipidea/usbmisc_imx.c | 22 +-
> 3 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index dedc33e..0991794 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -140,6 +140,9 @@ static struct imx_usbmisc_data
> *usbmisc_get_init_data(struct device *dev)
> if (of_find_property(np, "disable-over-current", NULL))
> data->disable_oc = 1;
>
> + if (of_find_property(np, "over-current-active-high", NULL))
> + data->oc_polarity = 1;
> +
> if (of_find_property(np, "external-vbus-divider", NULL))
> data->evdo = 1;
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.h
> b/drivers/usb/chipidea/ci_hdrc_imx.h
> index 635717e..409aa5ca8 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.h
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.h
> @@ -17,6 +17,7 @@ struct imx_usbmisc_data {
> int index;
>
> unsigned int disable_oc:1; /* over current detect disabled */
> + unsigned int oc_polarity:1; /* over current polarity if oc enabled */
> unsigned int evdo:1; /* set external vbus divider option */
> };
>
> diff --git a/drivers/usb/chipidea/usbmisc_imx.c
> b/drivers/usb/chipidea/usbmisc_imx.c
> index ab8b027..20d02a5 100644
> --- a/drivers/usb/chipidea/usbmisc_imx.c
> +++ b/drivers/usb/chipidea/usbmisc_imx.c
> @@ -56,6 +56,7 @@
>
> #define MX6_BM_NON_BURST_SETTING BIT(1)
> #define MX6_BM_OVER_CUR_DIS BIT(7)
> +#define MX6_BM_OVER_CUR_POLARITY BIT(8)
> #define MX6_BM_WAKEUP_ENABLE BIT(10)
> #define MX6_BM_ID_WAKEUP BIT(16)
> #define MX6_BM_VBUS_WAKEUP BIT(17)
> @@ -266,11 +267,14 @@ static int usbmisc_imx6q_init(struct imx_usbmisc_data
> *data)
>
> spin_lock_irqsave(&usbmisc->lock, flags);
>
> + reg = readl(usbmisc->base + data->index * 4);
> if (data->disable_oc) {
> - reg = readl(usbmisc->base + data->index * 4);
> - writel(reg | MX6_BM_OVER_CUR_DIS,
> - usbmisc->base + data->index * 4);
> + reg |= MX6_BM_OVER_CUR_DIS;
> + } else if (data->oc_polarity == 1) {
> + /* High active */
> + reg &= ~(MX6_BM_OVER_CUR_DIS | MX6_BM_OVER_CUR_POLARITY);
> }
> + writel(reg, usbmisc->base + data->index * 4);
>
> /* SoC non-burst setting */
> reg = readl(usbmisc->base + data->index * 4);
> @@ -365,10 +369,14 @@ static int usbmisc_imx7d_init(struct imx_usbmisc_data
> *data)
> return -EINVAL;
>
> spin_lock_irqsave(&usbmisc->lock, flags);
> + reg = readl(usbmisc->base);
> if (data->disable_oc) {
> - reg = readl(usbmisc->base);
> - writel(reg | MX6_BM_OVER_CUR_DIS, usbmisc->base);
> + reg |= MX6_BM_OVER_CUR_DIS;
> + } else if (data->oc_polarity == 1) {
> + /* High active */
> + reg &= ~(MX6_BM_OVER_CUR_DIS | MX6_BM_OVER_CUR_POLARITY);
> }
> + writel(reg, usbmisc->base);
>
> reg = readl(usbmisc->base + MX7D_USBNC_USB_CTRL2);
> reg &= ~MX7D_USB_VBUS_WAKEUP_SOURCE_MASK;
> @@ -492,6 +500,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
> .compatible = "fsl,imx6ul-usbmisc",
> .data = &imx6sx_usbmisc_ops,
> },
> + {
> + .compatible = "fsl,imx7d-usbmisc",
> + .data = &imx7d_usbmisc_ops,
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, usbmisc_imx_dt_ids);
> --
This one is ok, I will queue it
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v4] cdc_ether: Improve ZTE MF823/831/910 handling
The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.
When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.
This patch tries to improve the handling of ZTE devices by doing the
following:
* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.
* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.
* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.
* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.
This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.
I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.
v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).
v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* Rework logic in the ZTE bind-function a bit.
v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, as the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen
Acked-by: Oliver Neukum
---
drivers/net/usb/cdc_ether.c | 51 +
1 file changed, 51 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 7cba2c3..c47ec0a 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -388,6 +388,12 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
event->wValue ? "on" : "off");
+
+ /* Work-around for devices with broken off-notifications */
+ if (event->wValue &&
+ !test_bit(__LINK_STATE_NOCARRIER, &dev->net->state))
+ usbnet_link_change(dev, 0, 0);
+
usbnet_link_change(dev, !!event->wValue, 0);
break;
case USB_CDC_NOTIFY_SPEED_CHANGE: /* tx/rx rates */
@@ -432,6 +438,34 @@ int usbnet_cdc_bind(struct usbnet *dev, struct
usb_interface *intf)
}
EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
+static int usbnet_cdc_zte_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+ int status = usbnet_cdc_bind(dev, intf);
+
+ if (!status && (dev->net->dev_addr[0] & 0x02))
+ eth_hw_addr_random(dev->net);
+
+ return status;
+}
+
+/* Make sure packets have correct destination MAC address
+ *
+ * A firmware bug observed on some devices (ZTE MF823/831/910) is that the
+ * device sends packets with a static, bogus, random MAC address (event if
+ * device MAC address has been updated). Always set MAC address to that of the
+ * device.
+ */
+static int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+ if (skb->len < ETH_HLEN || !(skb->data[0] & 0x02))
+ return 1;
+
+ skb_reset_mac_
Re: [PATCH v3 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node
On Wed, Jul 20, 2016 at 05:40:28PM +0800, Peter Chen wrote: > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > index 69426e6..0d05812 100644 > --- a/drivers/usb/chipidea/core.c > +++ b/drivers/usb/chipidea/core.c > @@ -914,6 +914,16 @@ static int ci_hdrc_probe(struct platform_device *pdev) > if (!ci) > return -ENOMEM; > > + /* > + * At device tree, we have no device node for chipidea core, > + * the glue layer's node is the parent node for host and udc > + * device. But in related driver, the parent device is chipidea > + * core. So, in order to let the common driver get parent's node, > + * we let the core's device node equals glue layer's node. > + */ > + if (dev->parent && dev->parent->of_node) > + dev->of_node = dev->parent->of_node; This is a dangerous thing to do. You're changing the dev->of_node of _this_ device, which means that _this_ driver will no longer match the device if you remove and reinsert the driver module, or unbind and try to re-bind the device to this driver. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399
Hi Frank,
Am Donnerstag, 21. Juli 2016, 10:49:53 schrieb Frank Wang:
> >> @@ -69,6 +69,15 @@
> >>
> >> regulator-max-microvolt = <330>;
> >>
> >> };
> >>
> >> + vbus_host: vbus-host-regulator {
> >> + compatible = "regulator-fixed";
> >> + enable-active-high;
> >> + gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&host_vbus_drv>;
> >> + regulator-name = "vbus_host";
> >> + };
> >> +
> >
> > To match my schematics, this would probably be "vcc5v0_host".
> > Technically there are two regulators but since they are the same
> > voltage and enabled by the same GPIO it seems like modeling it as one
> > regulator is fine.
>
> Yep, you are right, I will rename it.
>
> > If you really wanted to model things you could also include the input
> > supply (VCC5V0_SYS). Not sure how much you care to model in EVB.
>
> Actually, from
> "Documentation/devicetree/bindings/regulator/fixed-regulator.txt" show,
> input supply name is just optional property, and it seems that only do
> assign "vin" value for input_supply (the second member of struct
> fixed_voltage_config) if "vin-supply" is specified.
>
> So is input supply name (VCC5V0_SYS) required here? Would you like to
> give more comments please?
While vin-supply is optional, I think that is meant for real top-level
regulators (our vcc_sys or whatever) that really don't have a parent
regulator.
It is always nicer to model the whole power-tree [in a sane way], as it makes
following the schematics a lot easier. If you mount a debugfs these days you
can even get a nice tree graph of the regulator infrastructure ... where the
parent-relationship is also needed to create something meaningful.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node
On Thu, Jul 21, 2016 at 10:14:38AM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 20, 2016 at 05:40:28PM +0800, Peter Chen wrote: > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > > index 69426e6..0d05812 100644 > > --- a/drivers/usb/chipidea/core.c > > +++ b/drivers/usb/chipidea/core.c > > @@ -914,6 +914,16 @@ static int ci_hdrc_probe(struct platform_device *pdev) > > if (!ci) > > return -ENOMEM; > > > > + /* > > +* At device tree, we have no device node for chipidea core, > > +* the glue layer's node is the parent node for host and udc > > +* device. But in related driver, the parent device is chipidea > > +* core. So, in order to let the common driver get parent's node, > > +* we let the core's device node equals glue layer's node. > > +*/ > > + if (dev->parent && dev->parent->of_node) > > + dev->of_node = dev->parent->of_node; > > This is a dangerous thing to do. You're changing the dev->of_node of > _this_ device, which means that _this_ driver will no longer match > the device if you remove and reinsert the driver module, or unbind > and try to re-bind the device to this driver. > Thanks for commenting it. I have tested load/unload, it does not show any problems. The chipidea core device is created by code at runtime, not by device node. And we have NO device node for this chipidea core device at dts. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node
On Thu, Jul 21, 2016 at 05:20:12PM +0800, Peter Chen wrote: > On Thu, Jul 21, 2016 at 10:14:38AM +0100, Russell King - ARM Linux wrote: > > On Wed, Jul 20, 2016 at 05:40:28PM +0800, Peter Chen wrote: > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > > > index 69426e6..0d05812 100644 > > > --- a/drivers/usb/chipidea/core.c > > > +++ b/drivers/usb/chipidea/core.c > > > @@ -914,6 +914,16 @@ static int ci_hdrc_probe(struct platform_device > > > *pdev) > > > if (!ci) > > > return -ENOMEM; > > > > > > + /* > > > + * At device tree, we have no device node for chipidea core, > > > + * the glue layer's node is the parent node for host and udc > > > + * device. But in related driver, the parent device is chipidea > > > + * core. So, in order to let the common driver get parent's node, > > > + * we let the core's device node equals glue layer's node. > > > + */ > > > + if (dev->parent && dev->parent->of_node) > > > + dev->of_node = dev->parent->of_node; > > > > This is a dangerous thing to do. You're changing the dev->of_node of > > _this_ device, which means that _this_ driver will no longer match > > the device if you remove and reinsert the driver module, or unbind > > and try to re-bind the device to this driver. > > > > Thanks for commenting it. > > I have tested load/unload, it does not show any problems. > > The chipidea core device is created by code at runtime, not by device node. > And we have NO device node for this chipidea core device at dts. Okay, so we still probably have the bind/unbind problem, where "dev" can be matched by the driver which claimed "dev->parent". Remember, in an OF environment, driver matching is done by the compatible property, which is accessed via dev->of_node. Therefore, I would suggest that you NULL dev->of_node in the error cleanup paths and in the remove function, so you don't have an unbound device with a duplicated (but inappropriate) dev->of_node pointer. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399
Hi Heiko,
On 2016/7/21 17:26, Heiko Stübner wrote:
Hi Frank,
Am Donnerstag, 21. Juli 2016, 10:49:53 schrieb Frank Wang:
@@ -69,6 +69,15 @@
regulator-max-microvolt = <330>;
};
+ vbus_host: vbus-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vbus_host";
+ };
+
To match my schematics, this would probably be "vcc5v0_host".
Technically there are two regulators but since they are the same
voltage and enabled by the same GPIO it seems like modeling it as one
regulator is fine.
Yep, you are right, I will rename it.
If you really wanted to model things you could also include the input
supply (VCC5V0_SYS). Not sure how much you care to model in EVB.
Actually, from
"Documentation/devicetree/bindings/regulator/fixed-regulator.txt" show,
input supply name is just optional property, and it seems that only do
assign "vin" value for input_supply (the second member of struct
fixed_voltage_config) if "vin-supply" is specified.
So is input supply name (VCC5V0_SYS) required here? Would you like to
give more comments please?
While vin-supply is optional, I think that is meant for real top-level
regulators (our vcc_sys or whatever) that really don't have a parent
regulator.
It is always nicer to model the whole power-tree [in a sane way], as it makes
following the schematics a lot easier. If you mount a debugfs these days you
can even get a nice tree graph of the regulator infrastructure ... where the
parent-relationship is also needed to create something meaningful.
Got it, many thanks for your explanation, I will add vin-supply next
version.
BR.
Frank
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node
On Thu, Jul 21, 2016 at 10:41:28AM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 21, 2016 at 05:20:12PM +0800, Peter Chen wrote: > > On Thu, Jul 21, 2016 at 10:14:38AM +0100, Russell King - ARM Linux wrote: > > > On Wed, Jul 20, 2016 at 05:40:28PM +0800, Peter Chen wrote: > > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > > > > index 69426e6..0d05812 100644 > > > > --- a/drivers/usb/chipidea/core.c > > > > +++ b/drivers/usb/chipidea/core.c > > > > @@ -914,6 +914,16 @@ static int ci_hdrc_probe(struct platform_device > > > > *pdev) > > > > if (!ci) > > > > return -ENOMEM; > > > > > > > > + /* > > > > +* At device tree, we have no device node for chipidea core, > > > > +* the glue layer's node is the parent node for host and udc > > > > +* device. But in related driver, the parent device is chipidea > > > > +* core. So, in order to let the common driver get parent's > > > > node, > > > > +* we let the core's device node equals glue layer's node. > > > > +*/ > > > > + if (dev->parent && dev->parent->of_node) > > > > + dev->of_node = dev->parent->of_node; > > > > > > This is a dangerous thing to do. You're changing the dev->of_node of > > > _this_ device, which means that _this_ driver will no longer match > > > the device if you remove and reinsert the driver module, or unbind > > > and try to re-bind the device to this driver. > > > > > > > Thanks for commenting it. > > > > I have tested load/unload, it does not show any problems. > > > > The chipidea core device is created by code at runtime, not by device node. > > And we have NO device node for this chipidea core device at dts. > > Okay, so we still probably have the bind/unbind problem, where "dev" > can be matched by the driver which claimed "dev->parent". Remember, > in an OF environment, driver matching is done by the compatible > property, which is accessed via dev->of_node. > > Therefore, I would suggest that you NULL dev->of_node in the error > cleanup paths and in the remove function, so you don't have an > unbound device with a duplicated (but inappropriate) dev->of_node > pointer. > Although it does no mismatch between driver and device due to the driver has no of_match_table, I find it has below re-request pinctrl error after re-bind, that's due to the parent device which has of_node and there is a pinctrl property in it. imx6sx-pinctrl 20e.iomuxc: pin MX6SX_PAD_GPIO1_IO10 already requested by 2184000.usb; cannot claim for ci_hdrc.0 After adding your suggestion, this error has gone, thanks. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: host: max3421-hcd: fix mask of IO control register
GPIO control register is divided into IOPINS1 and IOPINS2. And low 4-bit of register is controls output. So, this patch fixes wrong mask of GPIO output. Signed-off-by: Jaewon Kim --- drivers/usb/host/max3421-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c index c369c29..2f76900 100644 --- a/drivers/usb/host/max3421-hcd.c +++ b/drivers/usb/host/max3421-hcd.c @@ -1675,7 +1675,7 @@ max3421_gpout_set_value(struct usb_hcd *hcd, u8 pin_number, u8 value) if (pin_number > 7) return; - mask = 1u << pin_number; + mask = 1u << (pin_number % 4); idx = pin_number / 4; if (value) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/7] mfd: da8xx-cfgchip: New header file for CFGCHIP registers.
Hi, On Tuesday 10 May 2016 05:09 AM, David Lechner wrote: > We will be using a generic syscon device for the TI DA8XX SoC CFGCHIPx > retisters. This will be used by a number of planned drivers including a > new USB PHY driver and common clock framework drivers. > > The same defines are removed from the platform_data header file since they > are now redundant and they didn't really belong there anyway. > > Signed-off-by: David Lechner > Acked-by: Lee Jones > --- > include/linux/mfd/da8xx-cfgchip.h | 153 > ++ > include/linux/platform_data/usb-davinci.h | 22 - This patch as well is required for da8xx-usb phy since it uses da8xx-cfgchip.h. But I can't merge this as is since this removes macros in da8xx-cfgchip referenced in ohci-da8xx.c. So for now I'll split this patch and take only the part that adds da8xx-cfgchip.h. The part that removes macros from usb-davinci.h can go along with the USB patch series. Thanks Kishon > 2 files changed, 153 insertions(+), 22 deletions(-) > create mode 100644 include/linux/mfd/da8xx-cfgchip.h > > diff --git a/include/linux/mfd/da8xx-cfgchip.h > b/include/linux/mfd/da8xx-cfgchip.h > new file mode 100644 > index 000..304985e > --- /dev/null > +++ b/include/linux/mfd/da8xx-cfgchip.h > @@ -0,0 +1,153 @@ > +/* > + * TI DaVinci DA8xx CHIPCFGx registers for syscon consumers. > + * > + * Copyright (C) 2016 David Lechner > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#ifndef __LINUX_MFD_DA8XX_CFGCHIP_H > +#define __LINUX_MFD_DA8XX_CFGCHIP_H > + > +#include > + > +/* register offset (32-bit registers) */ > +#define CFGCHIP(n) ((n) * 4) > + > +/* CFGCHIP0 (PLL0/EDMA3_0) register bits */ > +#define CFGCHIP0_PLL_MASTER_LOCK BIT(4) > +#define CFGCHIP0_EDMA30TC1DBS(n) ((n) << 2) > +#define CFGCHIP0_EDMA30TC1DBS_MASK CFGCHIP0_EDMA30TC1DBS(0x3) > +#define CFGCHIP0_EDMA30TC1DBS_16 CFGCHIP0_EDMA30TC1DBS(0x0) > +#define CFGCHIP0_EDMA30TC1DBS_32 CFGCHIP0_EDMA30TC1DBS(0x1) > +#define CFGCHIP0_EDMA30TC1DBS_64 CFGCHIP0_EDMA30TC1DBS(0x2) > +#define CFGCHIP0_EDMA30TC0DBS(n) ((n) << 0) > +#define CFGCHIP0_EDMA30TC0DBS_MASK CFGCHIP0_EDMA30TC0DBS(0x3) > +#define CFGCHIP0_EDMA30TC0DBS_16 CFGCHIP0_EDMA30TC0DBS(0x0) > +#define CFGCHIP0_EDMA30TC0DBS_32 CFGCHIP0_EDMA30TC0DBS(0x1) > +#define CFGCHIP0_EDMA30TC0DBS_64 CFGCHIP0_EDMA30TC0DBS(0x2) > + > +/* CFGCHIP1 (eCAP/HPI/EDMA3_1/eHRPWM TBCLK/McASP0 AMUTEIN) register bits */ > +#define CFGCHIP1_CAP2SRC(n) ((n) << 27) > +#define CFGCHIP1_CAP2SRC_MASKCFGCHIP1_CAP2SRC(0x1f) > +#define CFGCHIP1_CAP2SRC_ECAP_PINCFGCHIP1_CAP2SRC(0x0) > +#define CFGCHIP1_CAP2SRC_MCASP0_TX CFGCHIP1_CAP2SRC(0x1) > +#define CFGCHIP1_CAP2SRC_MCASP0_RX CFGCHIP1_CAP2SRC(0x2) > +#define CFGCHIP1_CAP2SRC_EMAC_C0_RX_THRESHOLDCFGCHIP1_CAP2SRC(0x7) > +#define CFGCHIP1_CAP2SRC_EMAC_C0_RX CFGCHIP1_CAP2SRC(0x8) > +#define CFGCHIP1_CAP2SRC_EMAC_C0_TX CFGCHIP1_CAP2SRC(0x9) > +#define CFGCHIP1_CAP2SRC_EMAC_C0_MISCCFGCHIP1_CAP2SRC(0xa) > +#define CFGCHIP1_CAP2SRC_EMAC_C1_RX_THRESHOLDCFGCHIP1_CAP2SRC(0xb) > +#define CFGCHIP1_CAP2SRC_EMAC_C1_RX CFGCHIP1_CAP2SRC(0xc) > +#define CFGCHIP1_CAP2SRC_EMAC_C1_TX CFGCHIP1_CAP2SRC(0xd) > +#define CFGCHIP1_CAP2SRC_EMAC_C1_MISCCFGCHIP1_CAP2SRC(0xe) > +#define CFGCHIP1_CAP2SRC_EMAC_C2_RX_THRESHOLDCFGCHIP1_CAP2SRC(0xf) > +#define CFGCHIP1_CAP2SRC_EMAC_C2_RX CFGCHIP1_CAP2SRC(0x10) > +#define CFGCHIP1_CAP2SRC_EMAC_C2_TX CFGCHIP1_CAP2SRC(0x11) > +#define CFGCHIP1_CAP2SRC_EMAC_C2_MISCCFGCHIP1_CAP2SRC(0x12) > +#define CFGCHIP1_CAP1SRC(n) ((n) << 22) > +#define CFGCHIP1_CAP1SRC_MASKCFGCHIP1_CAP1SRC(0x1f) > +#define CFGCHIP1_CAP1SRC_ECAP_PINCFGCHIP1_CAP1SRC(0x0) > +#define CFGCHIP1_CAP1SRC_MCASP0_TX CFGCHIP1_CAP1SRC(0x1) > +#define CFGCHIP1_CAP1SRC_MCASP0_RX CFGCHIP1_CAP1SRC(0x2) > +#define CFGCHIP1_CAP1SRC_EMAC_C0_RX_THRESHOLDCFGCHIP1_CAP1SRC(0x7) > +#define CFGCHIP1_CAP1SRC_EMAC_C0_RX CFGCHIP1_CAP1SRC(0x8) > +#define CFGCHIP1_CAP1SRC_EMAC_C0_TX CFGCHIP1_CAP1SRC(0x9) > +#define CFGCHIP1_CAP1SRC_EMAC_C0_MISCCFGCHIP1_CAP1SRC(0xa) > +#define CFGCHIP1_CAP1SRC_EMAC_C1_R
Re: Fwd: USB HID problem
It seems the problem is related to 64 bit Linux on Gigabyte motherboards. 32 bit? No problem. Windows? No problem. Another mobo? No problem. So much for buying the preferred Linux mobo. I've added the GRUB_CMDLINE_LINUX= change to /etc/default/grub and updated with "update-bootloader". I hope that is the right substitute for "update-grub". I guess "bootloader" is some sort of name improvement over "grub" since grub is now pase. Welp, sending this out and about to reboot. CF: https://ubuntuforums.org/showthread.php?t=2111223&page=4 Re: GIGABYTE GA-970A-DS3 motherboard not working with 64 bit kernel Here is my updated fix First enable iommu in the uefi by restarting your computer and pressing delete to enter the uefi plug your usb mouse, keyboard and thumbdrive in usb 2 ports. save and exit the uefi Then In Ubuntu: press Ctrl+Alt+T to open up a terminal run the following command: sudo gedit /etc/default/grub Edit the empty quotes in this line to read: GRUB_CMDLINE_LINUX="iommu=soft" save changes to grub and exit gedit and the terminal Open up a new terminal with ctrl+alt+t run the following command: sudo update-grub then exit the terminal using this command: exit Restart your computer press delete to get back into the uefi Disable iommu in bios, load optimized defaults and restart. usb, 2.0 usb 3.0 and networking all work now in Ubuntu, and disabling iommu in bios helps prevent windows freezes that was occurring if you are running a dual boot environment. If the above post helps anyone I am happy. Last edited by ozcyto; May 29th, 2014 at 12:25 AM. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: USB HID problem
On Thu, 21 Jul 2016, Bruce Korb wrote: > It seems the problem is related to 64 bit Linux on Gigabyte motherboards. > 32 bit? No problem. Windows? No problem. Another mobo? No problem. > So much for buying the preferred Linux mobo. > I've added the GRUB_CMDLINE_LINUX= change to /etc/default/grub and > updated with "update-bootloader". I hope that is the right substitute for > "update-grub". I guess "bootloader" is some sort of name improvement > over "grub" > since grub is now pase. GRUB is not passé. Its name is an acronym for GRand Unified Bootloader. > > Welp, sending this out and about to reboot. > > CF: https://ubuntuforums.org/showthread.php?t=2111223&page=4 Good luck! Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] leds: trigger: Introduce an USB port trigger
On Wed, Jul 20, 2016 at 10:06:23AM +0200, Rafał Miłecki wrote:
> On 20 July 2016 at 03:02, Rob Herring wrote:
> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> >> This commit adds a new trigger that can turn on LED when USB device gets
> >> connected to the USB port. This can be useful for various home routers
> >> that have USB port and a proper LED telling user a device is connected.
> >>
> >> Right now this trigger is usable with a proper DT only, there isn't a
> >> way to specify USB ports from user space. This may change in a future.
> >>
> >> Signed-off-by: Rafał Miłecki
> >> ---
> >> V2: The first version got support for specifying list of USB ports from
> >> user space only. There was a (big try &) discussion on adding DT
> >> support. It led to a pretty simple solution of comparing of_node of
> >> usb_device to of_node specified in usb-ports property.
> >> Since it appeared DT support may be simpler and non-DT a bit more
> >> complex, this version drops previous support for "ports" and
> >> "new_port" and focuses on DT only. The plan is to see if this
> >> solution with DT is OK, get it accepted and then work on non-DT.
> >>
> >> Felipe: if there won't be any objections I'd like to ask for your Ack.
> >> ---
> >> Documentation/devicetree/bindings/leds/common.txt | 11 ++
> >> Documentation/leds/ledtrig-usbport.txt| 19 ++
> >> drivers/leds/trigger/Kconfig | 8 +
> >> drivers/leds/trigger/Makefile | 1 +
> >> drivers/leds/trigger/ledtrig-usbport.c| 206
> >> ++
> >> 5 files changed, 245 insertions(+)
> >> create mode 100644 Documentation/leds/ledtrig-usbport.txt
> >> create mode 100644 drivers/leds/trigger/ledtrig-usbport.c
> >>
> >> diff --git a/Documentation/devicetree/bindings/leds/common.txt
> >> b/Documentation/devicetree/bindings/leds/common.txt
> >> index af10678..75536f7 100644
> >> --- a/Documentation/devicetree/bindings/leds/common.txt
> >> +++ b/Documentation/devicetree/bindings/leds/common.txt
> >> @@ -50,6 +50,12 @@ property can be omitted.
> >> For controllers that have no configurable timeout the flash-max-timeout-us
> >> property can be omitted.
> >>
> >> +Trigger specific properties for child nodes:
> >> +
> >> +usbport trigger:
> >> +- usb-ports : List of USB ports that usbport should observed for turning
> >> on a
> >> + given LED.
> >
> > I think this should be more generic such that it could work for disk or
> > network LEDs too. Perhaps 'led-triggers = '? trigger is a bit of
> > a Linux name, but I haven't thought of anything better. Really, I'd
> > prefer the link in the other direction (e.g. port node have a 'leds" or
> > '*-leds' property), but that's maybe harder to parse.
>
> I was already thinking on this as I plan to add "netdev" trigger at
> some point in the future. I'd like to use "net-devices" for it (as a
> equivalent or "usb-ports").
>
> However there is a problem with your idea of sharing "led-triggers"
> between triggers.. Consider device with generic purpose LED that
> should be controllable by a user. I believe we should let user switch
> it's state, e.g. with:
> echo usbport > trigger
> echo netdev > trigger
> with a shared property I don't see how we couldn't handle it properly.
Well, the userspace interface and DT bindings are independent things.
You can't argue for what the DT binding should look like based on the
userspace interface.
Perhaps we need a "device trigger" where you echo the device to
be the trigger (similar to how bind works). If you have something to id
the device, then you can lookup its struct device and then its of_node
ptr.
The other problem with your userspace interface is it only works if
the trigger is defined in DT. It doesn't allow for specifying which usb
port or which netdev. Any trigger source should be assignable to any
LED? I can assign the disk activity trigger to the numlock LED if I
want to...
> I don't think we can use anything like:
> led-triggers = <&ohci_port1>, <&ehci_port1>, <ðmac0>;
> I'd get even more complicated if we ever need cells for any trigger.
> AFAIK it's not allowed to mix handles with different cells like:
> led-triggers = <&ohci_port1>, <&foo 5>, <ðmac0>;
It is allowed, but you would have to have a '#led-trigger-cells'
property in each phandle target.
> These problems made me use trigger-specific properies for specifying
> LED triggers. Do you have any other idea for sharing a property &
> avoiding above problems at the same time?
>
>
> >> +
> >> Examples:
> >>
> >> system-status {
> >> @@ -58,6 +64,11 @@ system-status {
> >> ...
> >> };
> >>
> >> +usb {
> >> + label = "USB";
> >
> > It's not really clear in the example this is an LED node as it is
> > incomplete.
>
> What do you mean by incomplete? Should I include e.g. ohci_port1 in
> this example?
label and usb-ports alone in this node does not make an LED node.
Re: [PATCH 1/2] usb: dwc2: optionally assert phy "full reset" when waking up
On Wed, Jul 20, 2016 at 10:54:33AM +0800, Randy Li wrote: > Thank you for reviewing, if you agree with my opinion, I would implement a > new version as soon as possible. > > > On 07/20/2016 09:36 AM, Rob Herring wrote: > >On Tue, Jul 19, 2016 at 08:05:33PM +0800, Randy Li wrote: > >>From: Doug Anderson > >> > >>On the rk3288 USB host-only port (the one that's not the OTG-enabled > >>port) the PHY can get into a bad state when a wakeup is asserted (not > >>just a wakeup from full system suspend but also a wakeup from > >>autosuspend). The problem is caused by a design fault in IC, Rockchip > >>have confirmed it and fix this problem in the future IC model. > >> > >>We can get the PHY out of its bad state by asserting its "port reset", > >>but unfortunately that seems to assert a reset onto the USB bus so it > >>could confuse things if we don't actually deenumerate / reenumerate the > >>device. > >> > >>We can also get the PHY out of its bad state by fully resetting it using > >>the reset from the CRU (clock reset unit), which does a more full > >>reset. The CRU-based reset appears to actually cause devices on the bus > >>to be removed and reinserted, which fixes the problem (albeit in a hacky > >>way). > >> > >>It's unfortunate that we need to do a full re-enumeration of devices at > >>wakeup time, but this is better than alternative of letting the bus get > >>wedged. > >> > >>Signed-off-by: Douglas Anderson > >>Signed-off-by: Yunzhi Li > >>Reviewed-by: Randy Li > >>--- > >> Documentation/devicetree/bindings/usb/dwc2.txt | 7 +++ > >> drivers/usb/dwc2/core.h| 5 + > >> drivers/usb/dwc2/core_intr.c | 14 ++ > >> drivers/usb/dwc2/platform.c| 13 + > >> 4 files changed, 39 insertions(+) > >> > >>diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt > >>b/Documentation/devicetree/bindings/usb/dwc2.txt > >>index 20a68bf..40c63ae 100644 > >>--- a/Documentation/devicetree/bindings/usb/dwc2.txt > >>+++ b/Documentation/devicetree/bindings/usb/dwc2.txt > >>@@ -20,6 +20,13 @@ Refer to clk/clock-bindings.txt for generic clock > >>consumer properties > >> Optional properties: > >> - phys: phy provider specifier > >> - phy-names: shall be "usb2-phy" > >>+- snps,need-phy-full-reset-on-wake: if present indicates that we need to > >>reset > >Bikeshedding, but 'snps,full-phy-reset-on-wake' is slightly shorter. > > > >However, this isn't really even needed. It should be implied by the SoC > >specific compatible string. > I would. > > > >>+ the PHY when we detect a wakeup due to a hardware errata. If present you > >>+ must specify a "phy-full-reset" reset. > >>+ > >>+Resets: > >>+- phy-full-reset (optional): Fully resets the PHY (Only used by rk3288 > >>Soc). > >This property belows in the phy node as that is where the reset is > >attached to and why is it not using the standard binding "resets"? > Because the struct phy_ops doesn't have something like reset method. It is > impossible to make a phy reset now. Also maybe it is not need to define a > reset at dts, just implied do that reset that in code(as the way to reset is > always same and only used by rk3288). Either the controller can retrieve the phy reset from the phy node or add a reset fn to struct phy_ops. The latter would be cleaner. If you don't put in DT at all and hard code in the driver, then I don't have an opinion. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
