How do I begin?
Hello, I am sorry if this has been posted by someone else before. I'd really like some help. So a little background: I'm a 17 year old Linux enthusiast. I've always wanted to contribute in any way to the kernel. Now I feel I can, so I picked up LDD3. I have little knowledge when it comes to the hardware part of things. However, I have a good understanding of C. I feel drivers would be a great way to begin and so I naturally came across this mailing list to ask my noob questions. I would like to desperately get into the kernel development process. I know my way around the Linux shell and have written my hello world module (which ran successfully, btw). I would like to know, however, how I can write my first legit patch and soon my first legit full-working driver and submit it to the Linux kernel. If someone can guide me as to how I can go about this, learning as much as possible about low level concepts, I would really appreciate it. -- Thanks a ton Vedant -- 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 v7 2/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
hi,
On Saturday 13 December 2014 05:49 AM, Doug Anderson wrote:
> Yunzhi,
>
> On Fri, Dec 12, 2014 at 7:07 AM, Yunzhi Li wrote:
>> This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
>> currently this driver can support RK3288. The RK3288 SoC have
>> three independent USB PHY IPs which are all configured through a
>> set of registers located in the GRF (general register files)
>> module.
>>
>> Signed-off-by: Yunzhi Li
>>
>> ---
>>
>> Changes in v7:
>> - Accept Kishon's comments to use phandle args to find a phy
>> struct directly and get rid of using a custom of_xlate
>> function.
>
> I'm going to assume you didn't test this version, since it doesn't
> work for me. At suspend time power is high and my printouts in the
> powerup/powerdown code aren't called...
>
>
>> + for_each_available_child_of_node(dev->of_node, child) {
>> + rk_phy = devm_kzalloc(dev, sizeof(*rk_phy), GFP_KERNEL);
>> + if (!rk_phy)
>> + return -ENOMEM;
>> +
>> + if (of_property_read_u32(child, "reg", ®_offset)) {
>> + dev_err(dev, "missing reg property in node %s\n",
>> + child->name);
>> + return -EINVAL;
>> + }
>> +
>> + rk_phy->reg_offset = reg_offset;
>> + rk_phy->reg_base = grf;
>> +
>> + rk_phy->clk = of_clk_get_by_name(child, "phyclk");
>> + if (IS_ERR(rk_phy->clk))
>> + rk_phy->clk = NULL;
>> +
>> + rk_phy->phy = devm_phy_create(dev, child, &ops);
>> + if (IS_ERR(rk_phy->phy)) {
>> + dev_err(dev, "failed to create PHY\n");
>> + return PTR_ERR(rk_phy->phy);
>> + }
>> + phy_set_drvdata(rk_phy->phy, rk_phy);
>> + }
>> +
>> + phy_provider = devm_of_phy_provider_register(dev,
>> of_phy_simple_xlate);
>
> I think your bug is here. I think you now need to register 3 phy
> providers, not just one.
No there should be only one phy provider. It means the bug is elsewhere.
Thanks
Kishon
--
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
query on DWC3
Hi Felipe,
In DWC3 driver, for three stage Control OUT transfer there is a check:
else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
&& (dep->number == 0)) {.
}
I understand that we check for alignment of sizes and if not we
prepare trb with maxpacket and enable interrupt on short packet. In
databook I could not find anything related to this, it talks only
about addresses should be aligned. In Control transfer programming
model there is no difference between Control OUT or IN transfer, if
three stage transfer - prepare trb with length wLength. Initially I
followed this and not able to receive data on EP0 OUT.:( .After adding
the above check it is working. Please help me to understand why we do
this?
Thank in advance,
Sundeep.B.S.
--
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 v7 2/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
Yunzhi,
On Fri, Dec 12, 2014 at 7:07 AM, Yunzhi Li wrote:
> This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
> currently this driver can support RK3288. The RK3288 SoC have
> three independent USB PHY IPs which are all configured through a
> set of registers located in the GRF (general register files)
> module.
>
> Signed-off-by: Yunzhi Li
>
> ---
>
> Changes in v7:
> - Accept Kishon's comments to use phandle args to find a phy
> struct directly and get rid of using a custom of_xlate
> function.
I'm going to assume you didn't test this version, since it doesn't
work for me. At suspend time power is high and my printouts in the
powerup/powerdown code aren't called...
> + for_each_available_child_of_node(dev->of_node, child) {
> + rk_phy = devm_kzalloc(dev, sizeof(*rk_phy), GFP_KERNEL);
> + if (!rk_phy)
> + return -ENOMEM;
> +
> + if (of_property_read_u32(child, "reg", ®_offset)) {
> + dev_err(dev, "missing reg property in node %s\n",
> + child->name);
> + return -EINVAL;
> + }
> +
> + rk_phy->reg_offset = reg_offset;
> + rk_phy->reg_base = grf;
> +
> + rk_phy->clk = of_clk_get_by_name(child, "phyclk");
> + if (IS_ERR(rk_phy->clk))
> + rk_phy->clk = NULL;
> +
> + rk_phy->phy = devm_phy_create(dev, child, &ops);
> + if (IS_ERR(rk_phy->phy)) {
> + dev_err(dev, "failed to create PHY\n");
> + return PTR_ERR(rk_phy->phy);
> + }
> + phy_set_drvdata(rk_phy->phy, rk_phy);
> + }
> +
> + phy_provider = devm_of_phy_provider_register(dev,
> of_phy_simple_xlate);
I think your bug is here. I think you now need to register 3 phy
providers, not just one.
I'll continue to assert my utter noviceness with this code, but my
attempt at a solution (which works) can be found at:
https://chromium-review.googlesource.com/235456
-Doug
--
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] renesas_usbhs: kill dead code in usbhs_probe()
usbhsc_drvcllbck_notify_hotplug() always returns 0, so it's rather pointless to store and check its result for being < 0. Signed-off-by: Sergei Shtylyov --- This patch is against the 'next' branch of Felipe Balbi's 'usb.git' repo. drivers/usb/renesas_usbhs/common.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) Index: usb/drivers/usb/renesas_usbhs/common.c === --- usb.orig/drivers/usb/renesas_usbhs/common.c +++ usb/drivers/usb/renesas_usbhs/common.c @@ -632,16 +632,12 @@ static int usbhs_probe(struct platform_d /* * manual call notify_hotplug for cold plug */ - ret = usbhsc_drvcllbck_notify_hotplug(pdev); - if (ret < 0) - goto probe_end_call_remove; + usbhsc_drvcllbck_notify_hotplug(pdev); dev_info(&pdev->dev, "probed\n"); return ret; -probe_end_call_remove: - usbhs_platform_call(priv, hardware_exit, pdev); probe_end_mod_exit: usbhs_mod_remove(priv); probe_end_fifo_exit: -- 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] renesas_usbhs: fix platform init error message
Hello.
On 11/05/2014 01:53 AM, Felipe Balbi wrote:
There is a typo ("prove" instead of "probe") in the error message printed when
the platform initialization fails. Replace that word with more fitting "init".
Signed-off-by: Sergei Shtylyov
this actually goes through me, I'll take it in a bit.
Felipe, I'm not seeing this patch anywhere in your tree. :-(
WBR, Sergei
--
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] xhci: Check if slot is already in default state before moving it there
Solves xhci error cases with debug messages:
xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1.
usb 1-6: hub failed to enable device, error -22
xhci will give a context state error if we try to set a slot in default
state to the same default state with a special address device command.
Turns out this happends in several cases:
- retry reading the device rescriptor in hub_port_init()
- usb_reset_device() is called for a slot in default state
- in resume path, usb_port_resume() calls hub_port_init()
The default state is usually reached from most states with a reset device
command without any context state errors, but using the address device
command with BSA bit set (block set address) only works from the enabled
state and will otherwise cause context error.
solve this by checking if we are already in the default state before issuing
a address device BSA=1 command.
Fixes: 48fc7dbd52c0 ("usb: xhci: change enumeration scheme to 'new scheme'")
Cc: # v3.14+
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5be1bff..7245163 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3803,6 +3803,15 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct
usb_device *udev,
return -EINVAL;
}
+ if (setup == SETUP_CONTEXT_ONLY) {
+ slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->out_ctx);
+ if (GET_SLOT_STATE(le32_to_cpu(slot_ctx->dev_state)) ==
+ SLOT_STATE_DEFAULT) {
+ xhci_dbg(xhci, "Slot already in default state\n");
+ return 0;
+ }
+ }
+
command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
if (!command)
return -ENOMEM;
--
1.8.3.2
--
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: [GIT PULL] USB driver fixes for 3.18-rc7
On 11.12.2014 20:47, Greg KH wrote: > On Wed, Dec 03, 2014 at 06:02:08PM +0200, Mathias Nyman wrote: >> On 02.12.2014 20:18, Greg KH wrote: >>> On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote: Hmm, Greg. I seem to get this problem possibly more commonly at boot these days: usb 1-6: new full-speed USB device number 2 using xhci_hcd usb 1-6: device descriptor read/64, error -71 xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. usb 1-6: hub failed to enable device, error -22 usb 1-6: new full-speed USB device number 3 using xhci_hcd usb 1-6: device descriptor read/64, error -71 usb 1-6: hub failed to enable device, error -22 usb 1-6: new full-speed USB device number 4 using xhci_hcd usb 1-6: Device not responding to setup address. usb 1-6: Device not responding to setup address. usb 1-6: device not accepting address 4, error -71 usb 1-6: new full-speed USB device number 5 using xhci_hcd usb 1-6: Device not responding to setup address. usb 1-6: Device not responding to setup address. usb 1-6: device not accepting address 5, error -71 usb usb1-port6: unable to enumerate USB device and my keyboard doesn't work. I then unplug and re-plug it, and get usb 1-6: new full-speed USB device number 9 using xhci_hcd usb 1-6: New USB device found, idVendor=2516, idProduct=0020 usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-6: Product: Quickfire Rapid i usb 1-6: Manufacturer: CM Storm Any ideas? Some setup delay that isn't long enough at boot time for a slightly finicky device? It has happened before, but now I've gotten it twice within a couple of days: Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 (I've had this keyboard since mid-September, and looking at the logs this machine has been rebooted 41 times since, with those three failures..) >>> >>> I've been seeing this occasionally recently as well, but was blaming a >>> "bad" USB 3 hub I have here that I use, and the problem goes away with a >>> replug. >>> >>> Mathias, any ideas what is going on here? >>> >> >> Looks like when xhci changed to use "new scheme" device enumeration for non >> SuperSpeed devices, we broke the device descriptor read retry for xhci. >> >> Normally we try to read the descriptor again, and if it still fails then >> fall back >> to old scheme. In this failing xhci case the slot is left in a default state >> after >> first failed descriptor read, and we then try to enable the slot again in >> retry, >> which is an invalid xhci context state change, and prints the error message: >> >> xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1 > > I see this all the time on my MinnowboardMax. For slot 2 that is. > > And on this machine, it does not boot from USB properly, I have to, > after the kernel comes up (which was read off of USB by UEFI just fine), > unplug and plug the storage device back in so that the boot process > continues. > > Works that way for 2 different USB 3.0 storage devices. > I got a patch that should fix the xhci "Setup ERROR" part in a setup-error-fix branch: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git setup-error-fix It's based on Gregs usb-next tree. It doesn't solve why the first device descritor read fails. >> After this It might be hard to get the device addressed. >> >> I don't know why it fail the first device descriptor read, but fixing the >> xhci part >> should allow more real reties. I'll work on it. >> >> The change to use xhci "new scheme" enumeration was done in 3.14 to support >> known >> legacy devices requiring it. commit 48fc7dbd52c0559647291f33a10ccdc6cdbe4c72 > > How can that break "non-legacy" devices? It added a enable_device callback for all usb2 devices during enumeration, which fails if called twice, or if the slot was already enabled in the xhci case. Caused whole enumeration to be aborted. -Mathias -- 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 v4 2/3] i2c: add support for Cypress CYUSBS234 USB-I2C adapter
Hi,
Thanks for reviewing the code.
> > +/*
> > + * It exposes sysfs entries under the i2c adapter for getting the i2c
> > +transfer
> > + * status, reset i2c read/write module, get/set nak and stop bits.
> > + */
>
> Yes, I see that. Yet, I don't know why they are needed? The driver should
> know when to send NAK/STOP. Why expose that to the user? And why do
> we need a reset? Are there stability problems? What about unloading the
> module? And what is the use case for reading the status?
For repeated start (Sr) scenario, the STOP bit will not be set.
For dummy write scenario (writing EEPROM address from I2C EEPROM slave), the
STOP bit should not be set. But, for normal I2C write, the STOP bit should be
set.
We provide control to user to control when to STOP/NAK to handle different
scenarios.
The reset is an additional provision given to user to reset the I2C read or
write engines. It does not require unloading I2C kernel module.
The status indicates the information about the last i2c read/write operation.
>
> > + if (num > 1) {
> > + dev_err(&adapter->dev, "i2c_msg number is > 1\n");
> > + return -EIO;
> > + }
>
> Ouch! Don't you have any repeated start option somewhere?
In this version of the driver, we handle only single i2c message. In future
iterations, we will add support for multiple i2c messages.
Thanks,
Muthu
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this message.
--
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 v7 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.
Get PHY parameters from devicetree and power off usb PHY during
system suspend.
Signed-off-by: Yunzhi Li
Acked-by: Paul Zimmerman
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Fix coding style: both branches of the if() which only one
branch of the conditional statement is a single statement
should have braces.
- No need to test dwc2->phy for NULL before calling generic phy
APIs.
drivers/usb/dwc2/gadget.c | 33 -
drivers/usb/dwc2/platform.c | 36 ++--
2 files changed, 46 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 200168e..2601c61 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3410,8 +3410,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
{
struct device *dev = hsotg->dev;
struct s3c_hsotg_plat *plat = dev->platform_data;
- struct phy *phy;
- struct usb_phy *uphy;
struct s3c_hsotg_ep *eps;
int epnum;
int ret;
@@ -3421,30 +3419,23 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
hsotg->phyif = GUSBCFG_PHYIF16;
/*
-* Attempt to find a generic PHY, then look for an old style
-* USB PHY, finally fall back to pdata
+* If platform probe couldn't find a generic PHY or an old style
+* USB PHY, fall back to pdata
*/
- phy = devm_phy_get(dev, "usb2-phy");
- if (IS_ERR(phy)) {
- uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(uphy)) {
- /* Fallback for pdata */
- plat = dev_get_platdata(dev);
- if (!plat) {
- dev_err(dev,
- "no platform data or transceiver defined\n");
- return -EPROBE_DEFER;
- }
- hsotg->plat = plat;
- } else
- hsotg->uphy = uphy;
- } else {
- hsotg->phy = phy;
+ if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
+ plat = dev_get_platdata(dev);
+ if (!plat) {
+ dev_err(dev,
+ "no platform data or transceiver defined\n");
+ return -EPROBE_DEFER;
+ }
+ hsotg->plat = plat;
+ } else if (hsotg->phy) {
/*
* If using the generic PHY framework, check if the PHY bus
* width is 8-bit and set the phyif appropriately.
*/
- if (phy_get_bus_width(phy) == 8)
+ if (phy_get_bus_width(hsotg->phy) == 8)
hsotg->phyif = GUSBCFG_PHYIF8;
}
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 6a795aa..ae095f0 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -155,6 +155,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
struct dwc2_core_params defparams;
struct dwc2_hsotg *hsotg;
struct resource *res;
+ struct phy *phy;
+ struct usb_phy *uphy;
int retval;
int irq;
@@ -212,6 +214,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
+ /*
+* Attempt to find a generic PHY, then look for an old style
+* USB PHY
+*/
+ phy = devm_phy_get(&dev->dev, "usb2-phy");
+ if (IS_ERR(phy)) {
+ hsotg->phy = NULL;
+ uphy = devm_usb_get_phy(&dev->dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(uphy))
+ hsotg->uphy = NULL;
+ else
+ hsotg->uphy = uphy;
+ } else {
+ hsotg->phy = phy;
+ phy_power_on(hsotg->phy);
+ phy_init(hsotg->phy);
+ }
+
spin_lock_init(&hsotg->lock);
mutex_init(&hsotg->init_mutex);
retval = dwc2_gadget_init(hsotg, irq);
@@ -231,8 +251,15 @@ static int __maybe_unused dwc2_suspend(struct device *dev)
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
- if (dwc2_is_device_mode(dwc2))
+ if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_suspend(dwc2);
+ } else {
+ if (dwc2->lx_state == DWC2_L0)
+ return 0;
+ phy_exit(dwc2->phy);
+ phy_power_off(dwc2->phy);
+
+ }
return ret;
}
@@ -241,8 +268,13 @@ static int __maybe_unused dwc2_resume(struct device *dev)
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
- if (dwc2_is_device_mode(dwc2))
+ if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_resume(dwc2);
+ } else
[PATCH] usb: usb-nop-xceiv.txt: Fix the description of 'vcc-supply'
From: Fabio Estevam
Since bd27fa44e13830d2b ("usb: phy: generic: Don't use regulator framework for
RESET line") we no longer model the reset line as a regulator supply, so
adapt the documentation accordingly.
Signed-off-by: Fabio Estevam
---
Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index 1bd37fa..8db5b33 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -13,7 +13,7 @@ Optional properties:
- clock-frequency: the clock frequency (in Hz) that the PHY clock must
be configured to.
-- vcc-supply: phandle to the regulator that provides RESET to the PHY.
+- vcc-supply: phandle to the regulator that provides power to the PHY.
- reset-gpios: Should specify the GPIO for reset.
--
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
[PATCH v7 2/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
currently this driver can support RK3288. The RK3288 SoC have
three independent USB PHY IPs which are all configured through a
set of registers located in the GRF (general register files)
module.
Signed-off-by: Yunzhi Li
---
Changes in v7:
- Accept Kishon's comments to use phandle args to find a phy
struct directly and get rid of using a custom of_xlate
function.
Changes in v6:
- Rename SIDDQ_MSK to SIDDQ_WRITE_ENA.
Changes in v5: None
Changes in v4:
- Get number of PHYs from device tree.
- Model each PHY as subnode of the phy provider node.
Changes in v3:
- Use BIT macro instead of bit shift ops.
- Rename the config entry to PHY_ROCKCHIP_USB.
drivers/phy/Kconfig| 7 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-usb.c | 158 +
3 files changed, 166 insertions(+)
create mode 100644 drivers/phy/phy-rockchip-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..b24500a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA
depends on OF
select GENERIC_PHY
+config PHY_ROCKCHIP_USB
+ tristate "Rockchip USB2 PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip USB 2.0 PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..48bf5a1 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) +=
phy-exynos5250-usb2.o
phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
+obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
new file mode 100644
index 000..22011c3
--- /dev/null
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -0,0 +1,158 @@
+/*
+ * Rockchip usb PHY driver
+ *
+ * Copyright (C) 2014 Yunzhi Li
+ * Copyright (C) 2014 ROCKCHIP, Inc.
+ *
+ * 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.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * The higher 16-bit of this register is used for write protection
+ * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
+ */
+#define SIDDQ_WRITE_ENABIT(29)
+#define SIDDQ_ON BIT(13)
+#define SIDDQ_OFF (0 << 13)
+
+struct rockchip_usb_phy {
+ unsigned intreg_offset;
+ struct regmap *reg_base;
+ struct clk *clk;
+ struct phy *phy;
+};
+
+static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
+ bool siddq)
+{
+ return regmap_write(phy->reg_base, phy->reg_offset,
+ SIDDQ_WRITE_ENA | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+}
+
+static int rockchip_usb_phy_power_off(struct phy *_phy)
+{
+ struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+ int ret = 0;
+
+ /* Power down usb phy analog blocks by set siddq 1 */
+ ret = rockchip_usb_phy_power(phy, 1);
+ if (ret)
+ return ret;
+
+ clk_disable_unprepare(phy->clk);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int rockchip_usb_phy_power_on(struct phy *_phy)
+{
+ struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+ int ret = 0;
+
+ ret = clk_prepare_enable(phy->clk);
+ if (ret)
+ return ret;
+
+ /* Power up usb phy analog blocks by set siddq 0 */
+ ret = rockchip_usb_phy_power(phy, 0);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .power_on = rockchip_usb_phy_power_on,
+ .power_off = rockchip_usb_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int rockchip_usb_phy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct rockchip_usb_phy *rk_phy;
+ struct phy_pr
Re: [PATCH] USB: serial: add nt124 usb to serial driver
Johan,
Thanks for the thorough review.
On Wed, Dec 10, 2014 at 7:04 AM, Johan Hovold wrote:
> On Mon, Dec 08, 2014 at 05:24:17PM -0600, George McCollister wrote:
>> This driver is for the NovaTech 124 4x serial expansion board for the
>> NovaTech OrionLXm.
>>
>> Firmware source code can be found here:
>> https://github.com/novatechweb/nt124
>
> Great, and thanks for the patch!
>
>> Signed-off-by: George McCollister
>> ---
>> drivers/usb/serial/Kconfig | 9 +
>> drivers/usb/serial/Makefile | 1 +
>> drivers/usb/serial/nt124.c | 429
>>
>> 3 files changed, 439 insertions(+)
>> create mode 100644 drivers/usb/serial/nt124.c
>>
>> diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
>> index a69f7cd..6dfc340 100644
>> --- a/drivers/usb/serial/Kconfig
>> +++ b/drivers/usb/serial/Kconfig
>> @@ -509,6 +509,15 @@ config USB_SERIAL_NAVMAN
>> To compile this driver as a module, choose M here: the
>> module will be called navman.
>>
>> +config USB_SERIAL_NT124
>> + tristate "USB nt124 serial device"
>
> USB NovaTech 124 Serial Driver (or NovaTech nt124)
I'll use USB NovaTech 124 Serial Driver
>
>> + help
>> + Say Y here if you want to use the NovaTech 124 4x USB to serial
>> + board.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called nt124.
>> +
>> config USB_SERIAL_PL2303
>> tristate "USB Prolific 2303 Single Port Serial Driver"
>> help
>> diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
>> index 349d9df..f88eaab 100644
>> --- a/drivers/usb/serial/Makefile
>> +++ b/drivers/usb/serial/Makefile
>> @@ -39,6 +39,7 @@ obj-$(CONFIG_USB_SERIAL_MOS7720)+= mos7720.o
>> obj-$(CONFIG_USB_SERIAL_MOS7840) += mos7840.o
>> obj-$(CONFIG_USB_SERIAL_MXUPORT) += mxuport.o
>> obj-$(CONFIG_USB_SERIAL_NAVMAN) += navman.o
>> +obj-$(CONFIG_USB_SERIAL_NT124) += nt124.o
>> obj-$(CONFIG_USB_SERIAL_OMNINET) += omninet.o
>> obj-$(CONFIG_USB_SERIAL_OPTICON) += opticon.o
>> obj-$(CONFIG_USB_SERIAL_OPTION) += option.o
>> diff --git a/drivers/usb/serial/nt124.c b/drivers/usb/serial/nt124.c
>> new file mode 100644
>> index 000..d7557ff
>> --- /dev/null
>> +++ b/drivers/usb/serial/nt124.c
>> @@ -0,0 +1,429 @@
>> +/*
>> + * nt124.c
>
> Put a brief description here instead.
Okay
>
>> + *
>> + * Copyright (c) 2014 NovaTech LLC
>> + *
>> + * Driver for nt124 4x serial board based on STM32F103
>
> For example use something like this above.
Okay
>
>> + *
>> + * Portions derived from the cdc-acm driver
>> + *
>> + * The original intention was to implement a cdc-acm compliant
>> + * 4x USB to serial converter in the STM32F103 however several problems
>> arose.
>> + * The STM32F103 didn't have enough end points to implement 4 ports.
>> + * CTS control was required by the application.
>> + * Accurate notification of transmission completion was required.
>> + * RTSCTS flow control support was required.
>> + *
>> + * The interrupt endpoint was eliminated and the control line information
>> + * was moved to the first two bytes of the in endpoint message. CTS control
>
> bulk in endpoint
Okay
>
>> + * and mechanisms to enable RTSCTS flow control and deliver TXEMPTY
>> + * information were added.
>> + *
>> + * Firmware source code can be found here:
>> + * https://github.com/novatechweb/nt124
>> + *
>> + * 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.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define NT124_VID0x2aeb
>> +#define NT124_USB_PID124
>> +
>> +#define DRIVER_AUTHOR "George McCollister "
>> +#define DRIVER_DESC "nt124 USB serial driver"
>
> Just use the MODULE macros directly (at the end of the file), no need
> for the defines.
Okay
>
>> +
>> +static const struct usb_device_id id_table[] = {
>> + { USB_DEVICE(NT124_VID, NT124_USB_PID) },
>> + { },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(usb, id_table);
>> +
>> +/*
>> + * Output control lines.
>> + */
>> +
>
> No new line.
Okay
>
>> +#define NT124_CTRL_DTR 0x01
>> +#define NT124_CTRL_RTS 0x02
>> +
>> +/*
>> + * Input control lines and line errors.
>> + */
>> +
>
> Same here.
Okay
>
>> +#define NT124_CTRL_DCD 0x01
>> +#defi
[PATCH v7 0/5] Patches to add support for Rockchip usb PHYs.
Patches to add support for Rockchip usb phys.Add a new Rockchip usb phy driver and modify dwc2 controller driver to make dwc2 platform devices support a generic PHY framework driver. This patch set has been tested on my rk3288-evb and power off the usb phys would reduce about 60mW power budget in total during sustem suspend. Changes in v7: - Update bindings doc - Accept Kishon's comments to use phandle args to find a phy struct directly and get rid of using a custom of_xlate function. - Update dtsi for new usb phy driver. Changes in v6: - Rename SIDDQ_MSK to SIDDQ_WRITE_ENA. Changes in v5: - Adjust entry order of example devicetree node in document. - reorder the phy dt node to a correct position. Changes in v4: - Updata description for phy device tree subnode. - Get number of PHYs from device tree. - Model each PHY as subnode of the phy provider node. - Add phy subnodes. Changes in v3: - Use BIT macro instead of bit shift ops. - Rename the config entry to PHY_ROCKCHIP_USB. - Fix coding style: both branches of the if() which only one branch of the conditional statement is a single statement should have braces. - No need to test dwc2->phy for NULL before calling generic phy APIs. Yunzhi Li (5): Documentation: bindings: add dt documentation for Rockchip usb PHY phy: add a driver for the Rockchip SoC internal USB2.0 PHY usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver. ARM: dts: rockchip: add rk3288 usb PHY ARM: dts: rockchip: Enable usb PHY on rk3288-evb board .../devicetree/bindings/phy/rockchip-usb-phy.txt | 37 + arch/arm/boot/dts/rk3288-evb.dtsi | 4 + arch/arm/boot/dts/rk3288.dtsi | 35 + drivers/phy/Kconfig| 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-usb.c | 158 + drivers/usb/dwc2/gadget.c | 33 ++--- drivers/usb/dwc2/platform.c| 36 - 8 files changed, 288 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt create mode 100644 drivers/phy/phy-rockchip-usb.c -- 2.0.0 -- 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 v7 0/5] Patches to add support for Rockchip usb PHYs.
Patches to add support for Rockchip usb phys.Add a new Rockchip usb phy driver and modify dwc2 controller driver to make dwc2 platform devices support a generic PHY framework driver. This patch set has been tested on my rk3288-evb and power off the usb phys would reduce about 60mW power budget in total during sustem suspend. Changes in v7: - Update bindings doc - Accept Kishon's comments to use phandle args to find a phy struct directly and get rid of using a custom of_xlate function. - Update dtsi for new usb phy driver. Changes in v6: - Rename SIDDQ_MSK to SIDDQ_WRITE_ENA. Changes in v5: - Adjust entry order of example devicetree node in document. - reorder the phy dt node to a correct position. Changes in v4: - Updata description for phy device tree subnode. - Get number of PHYs from device tree. - Model each PHY as subnode of the phy provider node. - Add phy subnodes. Changes in v3: - Use BIT macro instead of bit shift ops. - Rename the config entry to PHY_ROCKCHIP_USB. - Fix coding style: both branches of the if() which only one branch of the conditional statement is a single statement should have braces. - No need to test dwc2->phy for NULL before calling generic phy APIs. Yunzhi Li (5): Documentation: bindings: add dt documentation for Rockchip usb PHY phy: add a driver for the Rockchip SoC internal USB2.0 PHY usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver. ARM: dts: rockchip: add rk3288 usb PHY ARM: dts: rockchip: Enable usb PHY on rk3288-evb board .../devicetree/bindings/phy/rockchip-usb-phy.txt | 37 + arch/arm/boot/dts/rk3288-evb.dtsi | 4 + arch/arm/boot/dts/rk3288.dtsi | 35 + drivers/phy/Kconfig| 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-usb.c | 158 + drivers/usb/dwc2/gadget.c | 33 ++--- drivers/usb/dwc2/platform.c| 36 - 8 files changed, 288 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt create mode 100644 drivers/phy/phy-rockchip-usb.c -- 2.0.0 -- 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] uas: disable UAS on Apricorn SATA dongles
On Fri, Dec 12, 2014 at 11:42:12AM +0100, Hans de Goede wrote: > > > On 11-12-14 20:01, Darrick J. Wong wrote: > >The Apricorn SATA dongle will occasionally return "USBSUSBSUSB" in > >response to SCSI commands when running in UAS mode. Therefore, > >disable UAS mode on this dongle. > > > >Signed-off-by: Darrick J. Wong > > Looks good: > > Acked-by: Hans de Goede > > Greg, can you add this to your tree please ? Sure, will queue up after 3.19-rc1 is out. thanks, greg k-h -- 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] usb: gadget: udc-core: call udc_stop() before gadget unbind
> -Original Message- > From: Robert Baldyga [mailto:r.bald...@samsung.com] > Sent: Friday, December 12, 2014 2:17 PM > To: ba...@ti.com > Cc: gre...@linuxfoundation.org; peter.c...@freescale.com; linux- > u...@vger.kernel.org; linux-ker...@vger.kernel.org; > m.szyprow...@samsung.com; k.opas...@samsung.com; Robert Baldyga > Subject: [PATCH] usb: gadget: udc-core: call udc_stop() before > gadget unbind > > As usb function drivers assumes that all usb request will be > completed > before function unbind call, we should supply such behavior. In > some > cases ep_disable() won't kill all request effectively, because some > IN requests can be in running state. In such situation it's > possible > to have unbind function called before last request completion, > which > can cause problems. > > For example unbinding f_ecm function while request on 'notify' > endpoint > is not completed, ends up NULL pointer dereference in unbind() > function. > > usb_gadget_udc_stop() call causes completion of all requests so if > it's > called before gadget unbind there is no risk that some of requests > will > stay uncompleted. > > Signed-off-by: Robert Baldyga This finally solves issue described before in [1] Tested-by: Krzysztof Opasiak Footnotes: 1 - https://lkml.org/lkml/2014/12/9/283 -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics k.opas...@samsung.com -- 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: Query regarding USB gadget driver
Hello, On 12/12/2014 07:21 AM, Peter Chen wrote: > On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: >> Hi, >> >> On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: >>> Hello, >>> >>> I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core >>> is clocked at 500MHz and the USB IP core for this is by Chip-idea. I >>> am running a 3.18-rc5 kernel on it and trying to use the USB gadget >>> functionality. To be more specific the CDC ECM class. Currently, I >>> cannot use this properly. If I use just "ping" to check, it works >>> fine, but, after running iperf, even one transaction doesn't complete >>> or completes rarely. Checking the CDC Ether interface with Wireshark >>> shows, TCP Dup Ack messages and checking the USB bus with Wireshark, >>> shows packets with USB Protocol Error -71 at one point and after that >>> packets with USB connection Reset -104 error. If it's of any >>> significance, I have Arch Linux with the 3.18 kernel running on my >>> laptop with which the Vybrid connects. On the host side, the only >>> error dmesg shows is "kevent 12 may have been dropped". I guess this >>> is connected to the "TCP Previous Segment not captured" and "TCP Dup >>> ACK" messages. >>> >>> My script for the gadget configuration is as below: >>> >>> /bin/mount none /mnt -t configfs >>> /bin/mkdir /mnt/usb_gadget/g1 >>> cd /mnt/usb_gadget/g1 >>> /bin/mkdir configs/c.1 >>> /bin/mkdir functions/ecm.0 >>> /bin/mkdir strings/0x409 >>> /bin/mkdir configs/c.1/strings/0x409 >>> echo 0xa4a2 > idProduct >>> echo 0x0525 > idVendor >>> echo Freescale123 > strings/0x409/serialnumber >>> echo Freescale > strings/0x409/manufacturer >>> echo "USB Serial Gadget" > strings/0x409/product >>> echo "Conf 1" > configs/c.1/strings/0x409/configuration >>> echo 200 > configs/c.1/MaxPower >>> ln -s functions/ecm.0 configs/c.1 >>> echo ci_hdrc.0 > UDC >>> /sbin/ifconfig usb0 up >>> /sbin/ifconfig usb0 192.168.1.10 >>> >>> I have debug prints in the udc.c and u_ether.c using pr_debug and >> >> just a little hint, use any of the dev_*() macros next time, they'll >> print the device name which helps figuring out which UDC you're using. >> >> Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen >> maintains that one, it really helps adding maintainers to Cc list. >> >>> enable them when required using dynamic debug. Without running iperf, >>> using ping gives me a sequence of prints as below: >>> >>> [ 277.434409] In eth_start_xmit >>> [ 277.434517] In UDC irq >>> [ 277.434553] In usb_gadget_giveback_request >>> [ 277.434567] In tx_complete >>> [ 277.435443] In UDC irq >>> [ 277.435477] In usb_gadget_giveback_request >>> [ 277.435491] In rx_complete >>> [ 277.435517] In rx_submit >>> [ 277.435601] In eth_start_xmit >>> [ 277.436441] In UDC irq >>> [ 277.436465] In usb_gadget_giveback_request >>> [ 277.436478] In rx_complete >>> [ 277.436493] In rx_submit >>> [ 277.436520] In usb_gadget_giveback_request >>> [ 277.436533] In tx_complete >>> [ 278.434865] In eth_start_xmit >>> [ 278.434959] In UDC irq >>> [ 278.434993] In usb_gadget_giveback_request >>> [ 278.435006] In tx_complete >>> [ 278.435881] In UDC irq >>> [ 278.435910] In usb_gadget_giveback_request >>> [ 278.435923] In rx_complete >>> [ 278.435946] In rx_submit >>> >>> After running iperf without debug prints and then enabling before >>> using ping gives me a sequence of prints as below >>> [ 81.989827] In UDC irq >>> [ 81.989871] In usb_gadget_giveback_request >>> [ 81.989886] In rx_complete >>> [ 81.989905] In rx_submit >>> [ 82.989892] In UDC irq >>> [ 82.989951] In usb_gadget_giveback_request >>> [ 82.989967] In rx_complete >>> [ 82.989992] In rx_submit >>> [ 83.990064] In UDC irq >>> [ 83.990126] In usb_gadget_giveback_request >>> [ 83.990142] In rx_complete >>> [ 83.990167] In rx_submit >>> [ 84.990007] In UDC irq >>> [ 84.990049] In usb_gadget_giveback_request >>> [ 84.990064] In rx_complete >>> [ 84.990083] In rx_submit >>> [ 85.990085] In UDC irq >>> [ 85.990147] In usb_gadget_giveback_request >>> [ 85.990163] In rx_complete >>> [ 85.990188] In rx_submit >>> >>> If I force a full speed configuration for this USB client port, I get >>> a slightly more reliable operation where iperf can run for may be half >>> an hour or so or almost an hour before it falls through. Putting in a >>> delay of 100-150 microseconds in eth_start_xmit also improves it like >>> full speed, but, still not reliable. If I run iperf with debug prints >>> enable, this gives similar results to full speed config. After the >>> failure of iperf test, even ping doesn't work. Bringing down this usb0 >>> interface and then up again makes ping work again. I do realize that >>> putting debug prints or delays like this is not the right thing to do, >>> especially in ISR, but, just trying to debug. This is my first time >>> digging in the USB stack. >>> >>> Based on the above, it seems there might a subtle
Re: [PATCH 2/3] usb: chipidea: usbmisc_imx: delete clock information
Hi Peter,
Am Freitag, den 12.12.2014, 15:09 +0800 schrieb Peter Chen:
> All imx usb controller's non core registers uses the same clock gate with
> core registers, the usbmisc_imx is the library for imx glue driver, the
> glue keeps clock on when it calls usbmisc_imx API to change non-core register.
Is this true for all i.MX variants down to i.MX25?
> Besides, we will support runtime pm in the future, it also needs to
> close this clock when the usb is not in use.
I would have expected the clk_prepare_enable / disable_unprepare to
move from probe / remove into the init / post callbacks instead.
regards
Philipp
> Philipp Zabel also verifies it at imx6q platform, see
> http://www.spinics.net/lists/linux-usb/msg118491.html
>
> Cc: Philipp Zabel
> Signed-off-by: Peter Chen
> ---
> drivers/usb/chipidea/usbmisc_imx.c | 19 ---
> 1 file changed, 19 deletions(-)
>
> diff --git a/drivers/usb/chipidea/usbmisc_imx.c
> b/drivers/usb/chipidea/usbmisc_imx.c
> index 58591e9..e988e36 100644
> --- a/drivers/usb/chipidea/usbmisc_imx.c
> +++ b/drivers/usb/chipidea/usbmisc_imx.c
> @@ -11,7 +11,6 @@
>
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -69,7 +68,6 @@ struct usbmisc_ops {
> struct imx_usbmisc {
> void __iomem *base;
> spinlock_t lock;
> - struct clk *clk;
> const struct usbmisc_ops *ops;
> };
>
> @@ -322,7 +320,6 @@ static int usbmisc_imx_probe(struct platform_device *pdev)
> {
> struct resource *res;
> struct imx_usbmisc *data;
> - int ret;
> struct of_device_id *tmp_dev;
>
> data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> @@ -336,20 +333,6 @@ static int usbmisc_imx_probe(struct platform_device
> *pdev)
> if (IS_ERR(data->base))
> return PTR_ERR(data->base);
>
> - data->clk = devm_clk_get(&pdev->dev, NULL);
> - if (IS_ERR(data->clk)) {
> - dev_err(&pdev->dev,
> - "failed to get clock, err=%ld\n", PTR_ERR(data->clk));
> - return PTR_ERR(data->clk);
> - }
> -
> - ret = clk_prepare_enable(data->clk);
> - if (ret) {
> - dev_err(&pdev->dev,
> - "clk_prepare_enable failed, err=%d\n", ret);
> - return ret;
> - }
> -
> tmp_dev = (struct of_device_id *)
> of_match_device(usbmisc_imx_dt_ids, &pdev->dev);
> data->ops = (const struct usbmisc_ops *)tmp_dev->data;
> @@ -360,8 +343,6 @@ static int usbmisc_imx_probe(struct platform_device *pdev)
>
> static int usbmisc_imx_remove(struct platform_device *pdev)
> {
> - struct imx_usbmisc *usbmisc = dev_get_drvdata(&pdev->dev);
> - clk_disable_unprepare(usbmisc->clk);
> return 0;
> }
>
--
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: gadget: udc-core: call udc_stop() before gadget unbind
As usb function drivers assumes that all usb request will be completed before function unbind call, we should supply such behavior. In some cases ep_disable() won't kill all request effectively, because some IN requests can be in running state. In such situation it's possible to have unbind function called before last request completion, which can cause problems. For example unbinding f_ecm function while request on 'notify' endpoint is not completed, ends up NULL pointer dereference in unbind() function. usb_gadget_udc_stop() call causes completion of all requests so if it's called before gadget unbind there is no risk that some of requests will stay uncompleted. Signed-off-by: Robert Baldyga --- drivers/usb/gadget/udc/udc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c index e31d574..6f0d233 100644 --- a/drivers/usb/gadget/udc/udc-core.c +++ b/drivers/usb/gadget/udc/udc-core.c @@ -331,8 +331,8 @@ static void usb_gadget_remove_driver(struct usb_udc *udc) usb_gadget_disconnect(udc->gadget); udc->driver->disconnect(udc->gadget); - udc->driver->unbind(udc->gadget); usb_gadget_udc_stop(udc); + udc->driver->unbind(udc->gadget); udc->driver = NULL; udc->dev.driver = NULL; -- 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: [RFC PATCH] mfd: dln2: add support for ACPI
On Thu, Dec 11, 2014 at 11:44 PM, Rafael J. Wysocki wrote:
>
> On Thursday, December 11, 2014 06:32:07 PM Octavian Purdila wrote:
> > This patch adds support to load a custom ACPI table that describes
> > devices connected via the DLN2 USB to I2C/SPI/GPIO bridge.
> >
> > The ACPI table is loaded at runtime as firmware with the name
> > dln2.aml, it looks for an ACPI device entry with _HID set to
> > "DLN2" and makes it the ACPI companion for DLN2 USB sub-drivers.
>
> Why?
>
Hi Rafael,
Thanks for the review.
We are using this so that we can describe the resources for I2C
sensors we connect to the I2C bridge (i.e. the I2C address and the
GPIO number).
> > It is sort of a hack due to the "../acpi/internal.h" and
> > "../usb/core/usb.h" includes and perhaps something more generic would
> > be more appropriate. Any suggestions to the right direction are kindly
> > appreciated.
> >
> > Signed-off-by: Octavian Purdila
> > ---
> > Documentation/acpi/dln2-acpi.txt | 48 ++
> > drivers/mfd/Kconfig | 11 +
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/dln2-acpi.c | 103
> > +++
> > drivers/mfd/dln2.c | 6 +--
> > drivers/mfd/dln2.h | 9
> > 6 files changed, 173 insertions(+), 5 deletions(-)
> > create mode 100644 Documentation/acpi/dln2-acpi.txt
> > create mode 100644 drivers/mfd/dln2-acpi.c
> > create mode 100644 drivers/mfd/dln2.h
> >
> > diff --git a/Documentation/acpi/dln2-acpi.txt
> > b/Documentation/acpi/dln2-acpi.txt
> > new file mode 100644
> > index 000..c099241
> > --- /dev/null
> > +++ b/Documentation/acpi/dln2-acpi.txt
> > @@ -0,0 +1,48 @@
> > +Diolan DLN2 custom APCI table
> > +
> > +The Diolan DLN2 is an USB to I2C/SPI/GPIO bridge and as such it can be
> > used to
> > +connect to various I2C or SPI devices. Because these busses lack an
> > enumeration
> > +protocol, the driver obtains various information about the device (such as
> > I2C
> > +address and GPIO pins) from either ACPI or device tree.
> > +
> > +To allow using such devices connect to the DLN2 bridge to their full extend
> > +(e.g. interrupt mode), if CONFIG_MFD_DLN2_ACPI option has been compiled in
> > the
> > +kernel, the user can define a custom ACPI table that will be dynamically
> > loaded
> > +at boot time from firmware paths. The ACPI table filename must be dln2.aml
> > and
> > +it must contain a root device with _HID set "DLN2".
> > +
> > +Here is a example of how the ACPI table should look like:
> > +
> > +DefinitionBlock ("ssdt.aml", "SSDT", 1, "INTEL ", "CpuDptf", 0x0003)
> > +{
> > + Device (DLN0)
> > + {
> > + Name (_ADR, Zero)
> > + Name (_HID, "DLN2000")
> > +
> > + Device (STAC)
> > + {
> > + Name (_ADR, Zero)
> > + Name (_HID, "BMC150A")
> > + Name (_CID, "INTACCL")
> > + Name (_UID, One)
> > +
> > + Method (_CRS, 0, Serialized)
> > + {
> > + Name (RBUF, ResourceTemplate ()
> > + {
> > + I2cSerialBus (0x0010,
> > ControllerInitiated, 0x00061A80,
> > + AddressingMode7Bit,
> > "\\DLN0",
> > + 0x00, ResourceConsumer,
> > ,)
> > +
> > + GpioInt (Level, ActiveHigh,
> > Exclusive, PullDown, 0x,
> > + "\\DLN0", 0x00,
> > ResourceConsumer, , )
> > + { // Pin list
> > + 0
> > + }
> > + })
> > + Return (RBUF)
> > +}
> > + }
> > + }
> > +}
>
> Well, can you please explain here what the resources in the _CRS mean for
> this device? How they are supposed to be used etc.
>
OK.
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 2e6b731..b810195 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -205,6 +205,17 @@ config MFD_DLN2
> > etc. must be enabled in order to use the functionality of
> > the device.
> >
> > +config MFD_DLN2_ACPI
> > + bool "Diolan DLN2 ACPI support"
> > + depends on MFD_DLN2 && ACPI
> > + default n
> > + help
> > + Say yes here to add ACPI support to DLN2 which allows loading a
> > custom
> > + ACPI table to describe devices between the DLN2 I2C or SPI bridge as
> > + well as GPIO support for those devices. See
> > + Documentation/acpi/dln2-acpi.txt for more information.
> > +
> > +
> > config MFD_MC13XXX
> > tristate
> > depends on (SPI_MASTER || I2C)
> > diff --git a/drivers/mfd/Makefil
[PATCH 1/1] Revert "usb: chipidea: remove duplicate dev_set_drvdata for host_start"
This reverts commit 14b4099c074f2ddf4d84b22d370170e61b527529 It moved platform_set_drvdata(pdev, ci) before hcd is created, and the hcd will assign itself as ci controller's drvdata during the hcd creation function (in usb_create_shared_hcd), so it overwrites the real ci's drvdata which we want to use. So, if the controller is at host mode, the system suspend API will get the wrong struct ci_hdrc pointer, and cause the oops. Signed-off-by: Peter Chen --- drivers/usb/chipidea/core.c | 2 +- drivers/usb/chipidea/host.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index e14eafb..4f3c5a0 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -669,7 +669,6 @@ static int ci_hdrc_probe(struct platform_device *pdev) if (!ci) return -ENOMEM; - platform_set_drvdata(pdev, ci); ci->dev = dev; ci->platdata = dev_get_platdata(dev); ci->imx28_write_fix = !!(ci->platdata->flags & @@ -783,6 +782,7 @@ static int ci_hdrc_probe(struct platform_device *pdev) } } + platform_set_drvdata(pdev, ci); ret = devm_request_irq(dev, ci->irq, ci_irq, IRQF_SHARED, ci->platdata->name, ci); if (ret) diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c index c1694cf..48731d0 100644 --- a/drivers/usb/chipidea/host.c +++ b/drivers/usb/chipidea/host.c @@ -91,6 +91,7 @@ static int host_start(struct ci_hdrc *ci) if (!hcd) return -ENOMEM; + dev_set_drvdata(ci->dev, ci); hcd->rsrc_start = ci->hw_bank.phys; hcd->rsrc_len = ci->hw_bank.size; hcd->regs = ci->hw_bank.abs; -- 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
[PATCH 0/1] usb: chipidea: one bug fix for v3.19
Hi Greg, I find one bug that existed at chipidea driver in patch series which I sent you for v3.19, it will cause oops during the system suspend routine at host mode, hope it is not too late for merge. Apologize for that. Peter Chen (1): Revert "usb: chipidea: remove duplicate dev_set_drvdata for host_start" drivers/usb/chipidea/core.c | 2 +- drivers/usb/chipidea/host.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) -- 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: [sur40] Videobuf2 and/or DMA?
Hello Alan, On 11.12.2014 20:36, Alan Stern wrote: > On Sun, 7 Dec 2014, Florian Echtler wrote: >> - Can I always use DMA on the USB side (for bulk transfers), or does >> this in any way require support from the USB device's hardware? (I'm >> guessing no, but a definite answer would be great.) > DMA requires hardware support in the USB host controller, not in the > USB device. Most current USB host controllers support DMA; only a few > of the oldest ones don't. thanks - good to know for sure. AFAICT if I want to transfer bulk messages using DMA, I can't just use kalloc and usb_bulk_msg, but need usb_alloc_coherent, usb_fill_bulk_urb and usb_submit_urb, correct? Also, can you suggest any documentation regarding the relation between videobuf2 and DMA? Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] uas: disable UAS on Apricorn SATA dongles
On 11-12-14 20:01, Darrick J. Wong wrote: The Apricorn SATA dongle will occasionally return "USBSUSBSUSB" in response to SCSI commands when running in UAS mode. Therefore, disable UAS mode on this dongle. Signed-off-by: Darrick J. Wong Looks good: Acked-by: Hans de Goede Greg, can you add this to your tree please ? Regards, Hans --- drivers/usb/storage/unusual_uas.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h index 18a283d..3530cb0 100644 --- a/drivers/usb/storage/unusual_uas.h +++ b/drivers/usb/storage/unusual_uas.h @@ -40,6 +40,16 @@ * and don't forget to CC: the USB development list */ +/* + * Apricorn USB3 dongle sometimes returns "USBSUSBSUSBS" in response to SCSI + * commands in UAS mode. Observed with the 1.28 firmware; are there others? + */ +UNUSUAL_DEV(0x0984, 0x0301, 0x0128, 0x0128, + "Apricorn", + "", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_IGNORE_UAS), + /* https://bugzilla.kernel.org/show_bug.cgi?id=79511 */ UNUSUAL_DEV(0x0bc2, 0x2312, 0x, 0x, "Seagate", -- 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: UAS crash with Apricorn USB3 SATA bridge
Hi,
On 11-12-14 09:37, Darrick J. Wong wrote:
On Wed, Dec 10, 2014 at 05:41:54PM -0800, Darrick J. Wong wrote:
On Wed, Dec 10, 2014 at 02:29:29AM -0800, Darrick J. Wong wrote:
On Wed, Dec 10, 2014 at 02:15:14AM -0800, Darrick J. Wong wrote:
On Wed, Dec 10, 2014 at 01:04:58AM -0800, Darrick J. Wong wrote:
On Wed, Dec 10, 2014 at 09:19:04AM +0100, Hans de Goede wrote:
Hi,
On 09-12-14 20:31, Darrick J. Wong wrote:
Hi,
I have an Apricorn USB 3 disk dongle thing that claims to support UAS.
However, the kernel crashes when I plug it in[1].
Yes there are some known issues with uas error handling which are fixed
in 3.18, can you try with a 3.18 kernel please ?
The crash pic was from 3.18.0, blk_mq disabled. I'll work on getting a fuller
dmesg output. Looking at the code, it looks like we end up in
queue_bulk_sg_tx() with a sg list that is shorter than num_sgs, so we fall off
the end.
Well, there are (at least) two issues going on here. The first is that the
SCSI layer passes us zero-length READ10 commands, which is causing this crash.
Zero length means the sglist is empty, so the usb host has nothing to map, and
hence urb->num_mapped_sgs == 0 and the loop goes boom. I don't know what it
means to send a bulk URB with no buffers, so...
...then I took a tour of how SCSI LLDDs deal with zero-length read/write
commands. mpt2sas attaches a junk sg and pushes the command out. libata
detects zero-length READ/WRITE SCSI commands and completes the scsi command
without ever touching hardware. I wasn't able to get any of my parallel SCSI
disks to boot, so I could not try that.
The other problem is when I plug in a different disk (same mfg/model), READ
CAPACITY 16 intermittently returns the string "USBSUSBSUSBS", which of course
is garbage. The kernel then tries to use these values; fortunately, it rejects
a sector size of 1431519827 ("USBS") and sets the size to zero.
It turns out that this dongle will return "USBSUSBSUSB" to just about
*any* command, such as READ10. In fact, that's the root cause of the
crash. The partition code issues a 4k read to the disk (looking for
partition tables). The dongle returns "USBSUSBSUSB" (13 bytes) which
causes the bio to be advanced by 13 bytes because the URB's
actual_length is stuffed into the SCSI resid(ual length) field. The
block layer code now wants to read 4083 bytes starting at byte 13,
which, results in 3584 bytes being read ... to somewhere. This leaves
499 bytes in the bio, which is rounded down to 0 sectors, and thus we
crash on a zero-length READ10 when we try to read the remaining piece
and there's no sg to land the data. Worse yet, if you somehow patch
all *that* up, now the reader sees USBSUSBSUSB when the bio completes.
Let's disable UAS on this thing entirely. (Well, you /could/ hack it
to detect USBSUSBSUSB and fail the SCSI command entirely, but... meh.)
Though we should shortcut a zero-length read to avoid crashing the
kernel, since sg_raw can issue such commands.
Patches soon,
Thanks for all the time you've spend on this!
Disabling uas on this bridge sounds like the right thing to do to me.
A patch to not crash on 0 byte scsi data commands would indeed be welcome too.
Regards,
Hans
--D
So, I can code up a couple of patches -- one to teach UAS how to deal with zero
length read and writes; and a second patch to set US_FL_IGNORE_UAS on Apricorn
bridges. I tried setting US_FL_NO_READ_CAPACITY_16, but for whatever reason
sd.c was still trying RC16.
--D
(Alas it's now 1am here, so I'm going to bed. :/ )
Eh, nuts to sleeping. dmesg produces this:
[ 231.128074] usbcore: registered new interface driver usb-storage
[ 231.133822] usbcore: registered new interface driver uas
[ 252.121353] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd
[ 252.136927] scsi host6: uas
[ 252.141679] scsi 6:0:0:0: Direct-Access Apricorn 0128
PQ: 0 ANSI: 6
[ 252.145433] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 252.145525] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149
GiB)
[ 252.145527] sd 6:0:0:0: [sdc] 4096-byte physical blocks
[ 252.145891] sd 6:0:0:0: [sdc] Write Protect is off
[ 252.145973] sd 6:0:0:0: [sdc] No Caching mode page found
[ 252.145975] sd 6:0:0:0: [sdc] Assuming drive cache: write through
Huh. 4096-byte physical blocks?? That drive is /not/ a 4k sector drive.
Here's what the kernel said when I plugged in the other ("Plugable" brand) UAS
bridge[1]:
[ 32.466870] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd
[ 32.498996] usbcore: registered new interface driver usb-storage
[ 37.660963] scsi host6: uas
[ 37.661193] usbcore: registered new interface driver uas
[ 37.661292] queue_bulk_sg_tx: num=1 sg=880447764500 addr=45af41000 len=0
pagelink=ea00116bd042
[ 37.661550] queue_bulk_sg_tx: num=1 sg=8804483fb600 addr=45af41000 len=0
pagelink=ea00116bd042
[ 37.661744] scsi 6:0:0:0: Direct-Access Plugable USB3-SATA-
[PATCH 2/3] usb: chipidea: usbmisc_imx: delete clock information
All imx usb controller's non core registers uses the same clock gate with
core registers, the usbmisc_imx is the library for imx glue driver, the
glue keeps clock on when it calls usbmisc_imx API to change non-core register.
Besides, we will support runtime pm in the future, it also needs to
close this clock when the usb is not in use.
Philipp Zabel also verifies it at imx6q platform, see
http://www.spinics.net/lists/linux-usb/msg118491.html
Cc: Philipp Zabel
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/usbmisc_imx.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 58591e9..e988e36 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -11,7 +11,6 @@
#include
#include
-#include
#include
#include
#include
@@ -69,7 +68,6 @@ struct usbmisc_ops {
struct imx_usbmisc {
void __iomem *base;
spinlock_t lock;
- struct clk *clk;
const struct usbmisc_ops *ops;
};
@@ -322,7 +320,6 @@ static int usbmisc_imx_probe(struct platform_device *pdev)
{
struct resource *res;
struct imx_usbmisc *data;
- int ret;
struct of_device_id *tmp_dev;
data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
@@ -336,20 +333,6 @@ static int usbmisc_imx_probe(struct platform_device *pdev)
if (IS_ERR(data->base))
return PTR_ERR(data->base);
- data->clk = devm_clk_get(&pdev->dev, NULL);
- if (IS_ERR(data->clk)) {
- dev_err(&pdev->dev,
- "failed to get clock, err=%ld\n", PTR_ERR(data->clk));
- return PTR_ERR(data->clk);
- }
-
- ret = clk_prepare_enable(data->clk);
- if (ret) {
- dev_err(&pdev->dev,
- "clk_prepare_enable failed, err=%d\n", ret);
- return ret;
- }
-
tmp_dev = (struct of_device_id *)
of_match_device(usbmisc_imx_dt_ids, &pdev->dev);
data->ops = (const struct usbmisc_ops *)tmp_dev->data;
@@ -360,8 +343,6 @@ static int usbmisc_imx_probe(struct platform_device *pdev)
static int usbmisc_imx_remove(struct platform_device *pdev)
{
- struct imx_usbmisc *usbmisc = dev_get_drvdata(&pdev->dev);
- clk_disable_unprepare(usbmisc->clk);
return 0;
}
--
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
[PATCH 1/3] usb: chipidea: imx: using common platform flag directly
It is meaningless the glue layer driver has its own platform flag
which is the same meaning with common platform flag.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 450a168..33b4a7e 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -23,8 +23,6 @@
#include "ci.h"
#include "ci_hdrc_imx.h"
-#define CI_HDRC_IMX_IMX28_WRITE_FIX BIT(0)
-
struct ci_hdrc_imx_platform_flag {
unsigned int flags;
};
@@ -33,7 +31,7 @@ static const struct ci_hdrc_imx_platform_flag imx27_usb_data
= {
};
static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
- .flags = CI_HDRC_IMX_IMX28_WRITE_FIX,
+ .flags = CI_HDRC_IMX28_WRITE_FIX,
};
static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
@@ -145,9 +143,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
}
pdata.usb_phy = data->phy;
-
- if (imx_platform_flag->flags & CI_HDRC_IMX_IMX28_WRITE_FIX)
- pdata.flags |= CI_HDRC_IMX28_WRITE_FIX;
+ pdata.flags |= imx_platform_flag->flags;
ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
--
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
[PATCH 3/3] usb: chipidea: imx: simplify the usbmisc callers
Move struct imx_usbmisc_data NULL pointer judgement from caller to
each API, it can simplify the caller.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c | 22 --
drivers/usb/chipidea/usbmisc_imx.c | 12 ++--
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 33b4a7e..8fd7d0d 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -149,13 +149,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
- if (data->usbmisc_data) {
- ret = imx_usbmisc_init(data->usbmisc_data);
- if (ret) {
- dev_err(&pdev->dev, "usbmisc init failed, ret=%d\n",
- ret);
- goto err_clk;
- }
+ ret = imx_usbmisc_init(data->usbmisc_data);
+ if (ret) {
+ dev_err(&pdev->dev, "usbmisc init failed, ret=%d\n", ret);
+ goto err_clk;
}
data->ci_pdev = ci_hdrc_add_device(&pdev->dev,
@@ -169,13 +166,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
goto err_clk;
}
- if (data->usbmisc_data) {
- ret = imx_usbmisc_init_post(data->usbmisc_data);
- if (ret) {
- dev_err(&pdev->dev, "usbmisc post failed, ret=%d\n",
- ret);
- goto disable_device;
- }
+ ret = imx_usbmisc_init_post(data->usbmisc_data);
+ if (ret) {
+ dev_err(&pdev->dev, "usbmisc post failed, ret=%d\n", ret);
+ goto disable_device;
}
platform_set_drvdata(pdev, data);
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index e988e36..25839be 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -265,8 +265,12 @@ static const struct usbmisc_ops vf610_usbmisc_ops = {
int imx_usbmisc_init(struct imx_usbmisc_data *data)
{
- struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
+ struct imx_usbmisc *usbmisc;
+
+ if (!data)
+ return 0;
+ usbmisc = dev_get_drvdata(data->dev);
if (!usbmisc->ops->init)
return 0;
return usbmisc->ops->init(data);
@@ -275,8 +279,12 @@ EXPORT_SYMBOL_GPL(imx_usbmisc_init);
int imx_usbmisc_init_post(struct imx_usbmisc_data *data)
{
- struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
+ struct imx_usbmisc *usbmisc;
+
+ if (!data)
+ return 0;
+ usbmisc = dev_get_drvdata(data->dev);
if (!usbmisc->ops->post)
return 0;
return usbmisc->ops->post(data);
--
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
