Re: [PATCH 4/5] USB: bcma: add bcm53xx support

2015-06-02 Thread Rafał Miłecki 
On 2 June 2015 at 00:13, Hauke Mehrtens ha...@hauke-m.de wrote:
 @@ -159,6 +160,56 @@ static void bcma_hcd_init_chip(struct bcma_device *dev)
 }
  }

 +static void bcma_hcd_init_chip_arm(struct bcma_device *dev)
 +{
 +   struct bcma_device *arm_core;
 +   void __iomem *dmu;
 +   u32 val;
 +
 +   bcma_core_disable(dev, 0);
 +   bcma_core_enable(dev, 0);

This is quite unlikely you need to disable it manually, enable does it
for you. I guess it should be s/enable/reset/ to avoid such mistakes.
--
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 00/21] On-demand device registration

2015-06-02 Thread Linus Walleij 
On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
tomeu.viz...@collabora.com wrote:

 have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be possible
 to achieve the same by registering devices as they are referenced by other
 devices.

This is pretty cool, but a too local solution to a global problem.

Deferred probe and initcall reordering, silly as they may seem,
does not require you to use device tree.

The real solution, which I think I pointed out already when we
added deferred probe, is to put dependency graphs in the drivers
and have the kernel device driver core percolate dependecies by
walking the graph on probing driver, removing driver (usually the
inverse use case), [runtime] suspend and [runtime] resumeing
a driver. Possibly the dependencies will even be different
depending on use case.

This is what systemd is doing in userspace for starting services:
ask for your dependencies and wait for them if they are not
there. So drivers ask for resources and wait for them. It also
needs to be abstract, so for example we need to be able to
hang on regulator_get() until the driver is up and providing that
regulator, and as long as everything is in slowpath it should
be OK. (And vice versa mutatis mutandis for clk, gpio, pin
control, interrupts (!) and DMA channels for example.)


So if this should be solved it should be solved in an abstract way
in the device driver core available for all, then have calls calling
out to DT, ACPI, possibly even PCI or USB (as these
enumerate devices themselves) to obtain a certain
dependency.

Yours,
Linus Walleij
--
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 3/5] USB: bcma: use devm_kzalloc

2015-06-02 Thread Rafał Miłecki 
On 2 June 2015 at 00:13, Hauke Mehrtens ha...@hauke-m.de wrote:
 @@ -239,10 +240,8 @@ static int bcma_hcd_probe(struct bcma_device *dev)
 ohci_addr = 0x18009000;

 usb_dev-ohci_dev = bcma_hcd_create_pdev(dev, true, ohci_addr);
 -   if (IS_ERR(usb_dev-ohci_dev)) {
 -   err = PTR_ERR(usb_dev-ohci_dev);
 -   goto err_free_usb_dev;
 -   }
 +   if (IS_ERR(usb_dev-ohci_dev))
 +   return PTR_ERR(usb_dev-ohci_dev);

 usb_dev-ehci_dev = bcma_hcd_create_pdev(dev, false, dev-addr);
 if (IS_ERR(usb_dev-ehci_dev)) {

Just noticed something: bcma_hcd_create_pdev can return NULL.
Can you handle this, please? No need to modify this patch probably
(you don't make anything worse with it), maybe just do it in separated
one?

-- 
Rafał
--
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 1/1] cdc-acm: Add support of ATOL FPrint fiscal printers

2015-06-02 Thread Ben Dooks 
On 02/06/15 11:05, Alexey Sokolov wrote:
 ATOL FPrint fiscal printers require usb_clear_halt to be executed
 to work properly. Add quirk to fix the issue.
 
 Signed-off-by: Alexey Sokolov soko...@7pikes.com
 ---
  drivers/usb/class/cdc-acm.c | 9 +
  drivers/usb/class/cdc-acm.h | 1 +
  2 files changed, 10 insertions(+)
 
 diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
 index 5c8f581..9d8a321 100644
 --- a/drivers/usb/class/cdc-acm.c
 +++ b/drivers/usb/class/cdc-acm.c
 @@ -1477,6 +1477,11 @@ skip_countries:
   goto alloc_fail8;
   }
  
 + if (quirks == CLEAR_HALT_CONDITIONS) {
 + usb_clear_halt(usb_dev, usb_rcvbulkpipe(usb_dev, 
 epread-bEndpointAddress));
 + usb_clear_halt(usb_dev, usb_sndbulkpipe(usb_dev, 
 epwrite-bEndpointAddress));
 + }
 +

Given quirks looks like a bitfield, it would be better if this is

if (quirks  CLEAR_HALT_CONDITIONS) {


-- 
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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/1] cdc-acm: Add support of ATOL FPrint fiscal printers

2015-06-02 Thread Alexey Sokolov 
ATOL FPrint fiscal printers require usb_clear_halt to be executed
to work properly. Add quirk to fix the issue.

Signed-off-by: Alexey Sokolov soko...@7pikes.com
---
 drivers/usb/class/cdc-acm.c | 9 +
 drivers/usb/class/cdc-acm.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 5c8f581..a086e1d 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1477,6 +1477,11 @@ skip_countries:
goto alloc_fail8;
}
 
+   if (quirks  CLEAR_HALT_CONDITIONS) {
+   usb_clear_halt(usb_dev, usb_rcvbulkpipe(usb_dev, 
epread-bEndpointAddress));
+   usb_clear_halt(usb_dev, usb_sndbulkpipe(usb_dev, 
epwrite-bEndpointAddress));
+   }
+
return 0;
 alloc_fail8:
if (acm-country_codes) {
@@ -1756,6 +1761,10 @@ static const struct usb_device_id acm_ids[] = {
.driver_info = NO_UNION_NORMAL, /* reports zero length descriptor */
},
 
+   { USB_DEVICE(0x2912, 0x0001), /* ATOL FPrint */
+   .driver_info = CLEAR_HALT_CONDITIONS,
+   },
+
/* Nokia S60 phones expose two ACM channels. The first is
 * a modem and is picked up by the standard AT-command
 * information below. The second is 'vendor-specific' but
diff --git a/drivers/usb/class/cdc-acm.h b/drivers/usb/class/cdc-acm.h
index ffeb3c8..b3b6c9d 100644
--- a/drivers/usb/class/cdc-acm.h
+++ b/drivers/usb/class/cdc-acm.h
@@ -133,3 +133,4 @@ struct acm {
 #define NO_DATA_INTERFACE  BIT(4)
 #define IGNORE_DEVICE  BIT(5)
 #define QUIRK_CONTROL_LINE_STATE   BIT(6)
+#define CLEAR_HALT_CONDITIONS  BIT(7)
-- 
2.4.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 1/1] USB-SERIAL : Changing usb_serial_generic_open prototype

2015-06-02 Thread Abhishek bist 
Yes, I gone through this warning. It is because if i want to make this
compilation warning free
than i have to change the prototype of a open function pointer
described in usb_serial_driver
and changing the prototype over there would affect all the device
driver lying in usb-serial
category , which is definitely not recommended.
  Anyways i got your point .

Thanks
Abhishek-bist

On 1 June 2015 at 20:00, Johan Hovold jo...@kernel.org wrote:
 On Sat, May 30, 2015 at 06:47:20PM +0530, Abhishek Bist wrote:
 While designing a usb to uart converter driver open function I am using
 usb_serial_generic_open, but wouldn't find need to pass tty as an argument.
 As it is not performing any task for further significance.
   So, This patch proposed a change in usb_serial_generic_open
 function prototype which has struct tty_struct as a first argument.

 usb_serial_generic_open(struct tty_struct *tty,
   struct usb_serial_port *port);

 Signed-off-by: Abhishek Bist ishub...@gmail.com

 diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
 index 704a1ab..c8ed44a 100644
 --- a/include/linux/usb/serial.h
 +++ b/include/linux/usb/serial.h
 @@ -318,8 +318,7 @@ static inline void usb_serial_console_disconnect(struct 
 usb_serial *serial) {}
  /* Functions needed by other parts of the usbserial core */
  extern struct usb_serial_port *usb_serial_port_get_by_minor(unsigned int 
 minor);
  extern void usb_serial_put(struct usb_serial *serial);
 -extern int usb_serial_generic_open(struct tty_struct *tty,
 - struct usb_serial_port *port);
 +extern int usb_serial_generic_open(struct usb_serial_port *port);
  extern int usb_serial_generic_write_start(struct usb_serial_port *port,
   gfp_t mem_flags);
  extern int usb_serial_generic_write(struct tty_struct *tty,

 This does not work as usb_serial_generic_open is the default driver
 callback.

 If you had compile tested your patch you would have seen the following
 warning:

 linux/drivers/usb/serial/usb-serial.c: In function 
 'usb_serial_operations_init':
 linux/drivers/usb/serial/usb-serial.c:1318:19: warning: assignment from 
 incompatible pointer type
 type-function = usb_serial_generic_##function; \
^
 linux/drivers/usb/serial/usb-serial.c:1326:2: note: in expansion of macro 
 'set_to_generic_if_null'
   set_to_generic_if_null(device, open);
   ^

 Johan
--
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 1/1] cdc-acm: Add support of ATOL FPrint fiscal printers

2015-06-02 Thread Oliver Neukum 
On Tue, 2015-06-02 at 11:05 +0300, Alexey Sokolov wrote:
 ATOL FPrint fiscal printers require usb_clear_halt to be executed
 to work properly. Add quirk to fix the issue.
 


Hi,

thank you for this patch.

 Signed-off-by: Alexey Sokolov soko...@7pikes.com
 ---
  drivers/usb/class/cdc-acm.c | 9 +
  drivers/usb/class/cdc-acm.h | 1 +
  2 files changed, 10 insertions(+)
 
 diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
 index 5c8f581..9d8a321 100644
 --- a/drivers/usb/class/cdc-acm.c
 +++ b/drivers/usb/class/cdc-acm.c
 @@ -1477,6 +1477,11 @@ skip_countries:
   goto alloc_fail8;
   }
  
 + if (quirks == CLEAR_HALT_CONDITIONS) {

Please make that
quirks  CLEAR_HALT_CONDITIONS

Regards
Oliver

--
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 1/2] Bluetooth: Add reset_resume function

2015-06-02 Thread Oliver Neukum 
On Mon, 2015-06-01 at 18:14 -0700, Laura Abbott wrote:
 Bluetooth devices off of some buses such as USB may lose power across
 suspend/resume. When this happens, drivers may need to have the setup
 function called again and behave differently than a cold power on.

Yes, but what is the point? We use reset_resume() to retain
some features of a device across a loss of power.
If power is lost, all settings are gone and all connections
are broken. So what is the difference compared to a plug out/in
cycle?

Regards
Oliver



--
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 RFC 2/2] cdc_ncm: split the cdc_ncm_ndp funciton

2015-06-02 Thread Enrico Mioso 
Split this function in two new ones:
- cdc_ncm_ndp16_find: finds an NDP block in the chain mathcing a supplied
  signature; a pointer to it is returned in case of success;
- cdc_ncm_ndp16_push: create and add to skb a new NDP block;

cdc_ncm_ndp16_push refers to the last NDP visited by cdc_ncm_ndp16_find, hence
this code is stateful.

Signed-Off-By: Enrico Mioso mrkiko...@gmail.com
---
 drivers/net/usb/cdc_ncm.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 8067b8f..3c837d6 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -980,7 +980,7 @@ static void cdc_ncm_align_tail(struct sk_buff *skb, size_t 
modulus, size_t remai
 /* return a pointer to a valid struct usb_cdc_ncm_ndp16 of type sign, possibly
  * allocating a new one within skb
  */
-static struct usb_cdc_ncm_ndp16 *cdc_ncm_ndp(struct cdc_ncm_ctx *ctx, struct 
sk_buff *skb, __le32 sign, size_t reserve)
+static struct usb_cdc_ncm_ndp16 *cdc_ncm_ndp16_find(struct cdc_ncm_ctx *ctx, 
struct sk_buff *skb, __le32 sign)
 {
struct usb_cdc_ncm_ndp16 *ndp16 = NULL;
struct usb_cdc_ncm_nth16 *nth16 = (void *)skb-data;
@@ -988,12 +988,20 @@ static struct usb_cdc_ncm_ndp16 *cdc_ncm_ndp(struct 
cdc_ncm_ctx *ctx, struct sk_
 
/* follow the chain of NDPs, looking for a match */
while (ndpoffset) {
-   ndp16 = (struct usb_cdc_ncm_ndp16 *)(skb-data + ndpoffset);
-   if  (ndp16-dwSignature == sign)
-   return ndp16;
+   ctx-tx_curr_ndp16 = (struct usb_cdc_ncm_ndp16 *)(skb-data + 
ndpoffset);
+   if (ctx-tx_curr_ndp16-dwSignature == sign)
+   ndp16 = ctx-tx_curr_ndp16;
ndpoffset = le16_to_cpu(ndp16-wNextNdpIndex);
}
+  
+  return ndp16;
+}
 
+static struct usb_cdc_ncm_ndp16 *cdc_ncm_ndp16_push(struct cdc_ncm_ctx *ctx, 
struct sk_buff *skb, __le32 sign, size_t reserve)
+{
+   struct usb_cdc_ncm_ndp16 *ndp16 = ctx-tx_curr_ndp16;
+   struct usb_cdc_ncm_nth16 *nth16 = (void *)skb-data;
+  
/* align new NDP */
cdc_ncm_align_tail(skb, ctx-tx_ndp_modulus, 0, ctx-tx_max);
 
@@ -1070,11 +1078,15 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct 
sk_buff *skb, __le32 sign)
break;
}
 
-   /* get the appropriate NDP for this skb */
-   ndp16 = cdc_ncm_ndp(ctx, skb_out, sign, skb-len + 
ctx-tx_modulus + ctx-tx_remainder);
-
-   /* align beginning of next frame */
-   cdc_ncm_align_tail(skb_out,  ctx-tx_modulus, 
ctx-tx_remainder, ctx-tx_max);
+   /* search for the appropriate NDP for this skb */
+   ndp16 = cdc_ncm_ndp16_find(ctx, skb_out, sign);
+   
+   if (ndp16 == NULL)
+   {
+ ndp16 = cdc_ncm_ndp16_push(ctx, skb_out, sign, skb-len + 
ctx-tx_modulus + ctx-tx_remainder);
+   }
+else
+ cdc_ncm_align_tail(skb_out,  ctx-tx_modulus, 
ctx-tx_remainder, ctx-tx_max);
 
/* check if we had enough room left for both NDP and frame */
if (!ndp16 || skb_out-len + skb-len  ctx-tx_max) {
-- 
2.4.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

[PATCH RFC 1/2] cdc_ncm: add the currently processed NDP frame to global driver data

2015-06-02 Thread Enrico Mioso 
This is useful to split up the cdc_ncm_ndp function later on.
The resulting code will be anyway stateful.

Signed-Off-By: Enrico Mioso mrkiko...@gmail.com
---
 include/linux/usb/cdc_ncm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index 7c9b484..9172256 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -100,6 +100,7 @@ struct cdc_ncm_ctx {
struct sk_buff *tx_curr_skb;
struct sk_buff *tx_rem_skb;
__le32 tx_rem_sign;
+   struct usb_cdc_ncm_ndp16 *tx_curr_ndp16;
 
spinlock_t mtx;
atomic_t stop;
-- 
2.4.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

[PATCH RFC 0/2] cdc_ncm refactoring

2015-06-02 Thread Enrico Mioso 
I changed my mind, and decided to try in following this new way.
This series splits the cdc_ncm_ndp function in two parts:
- one that finds NDP blocks already present in the SKB being sent out
- one that pushes new ones, starting from where the _find function left.

After this splitting it seems more easy to modify the location where the NDP is 
disposed.
What do you think about this?

From now on, I need a little bit of help: I think we might work on the 
cdc_ncm_ndp16_push function, still I am open to any suggestion.

Let me know if you like this.
Enrico

Enrico Mioso (2):
  cdc_ncm: add the currently processed NDP frame to global driver data
  cdc_ncm: split the cdc_ncm_ndp funciton

 drivers/net/usb/cdc_ncm.c   | 30 +-
 include/linux/usb/cdc_ncm.h |  1 +
 2 files changed, 22 insertions(+), 9 deletions(-)

-- 
2.4.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: [PATCH v4 0/2] Remaining sunxi musb patches

2015-06-02 Thread Hans de Goede 

Hi,

On 01-06-15 20:34, Felipe Balbi wrote:

On Mon, Jun 01, 2015 at 11:30:45AM -0700, Hans de Goede wrote:

Hi,

On Sunday, May 31, 2015 at 6:10:32 PM UTC+2, Hans de Goede wrote:


Hi Kishon  Felipe,

Here is an updated version of the remaining (not yet merged in Felipe's
tree)
sunxi musb patches.

The phy-sun4i-usb: Add full support for usb0 phy / OTG patch has been
updated with a small bug-fix and is ready for merging.

The musb: Add support for the Allwinner sunxi musb patch has been
updated
to use the latest version of Maxime's sunxi sram controller driver. This
one has a compile-time dependency on Maxime's sunxi sram controller
driver,
so it cannot be merged until that is merged.




Arnd has just merged the updated sram controller into the next branch
of the soc-drivers repo, so both these patches are now ready to merge.


all right, so for v4.3 merge window there will be no issues in queues
the two remaining patches. Thanks


So I take it that it is too late to get these 2 into 4.2 ? I've a bunch
of (small) follow up patches coming up to enable support for the musb
controller on new boards, merging those would be easier if these were
already merged. And there also is a largish set of sunxi dts patches
actually enabling the musb code which is sorta waiting for merging
these 2 (waiting for the dt binding to be stable).

If this is not going to make 4.2, can you and Kishon at least review
them and let me know of they will get merged for 4.3 as is (baring
any merge issues) ?

Regards,

Hans
--
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/1] cdc-acm: Add support of ATOL FPrint fiscal printers

2015-06-02 Thread Alexey Sokolov 
ATOL FPrint fiscal printers require usb_clear_halt to be executed
to work properly. Add quirk to fix the issue.

Signed-off-by: Alexey Sokolov soko...@7pikes.com
---
 drivers/usb/class/cdc-acm.c | 9 +
 drivers/usb/class/cdc-acm.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 5c8f581..9d8a321 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1477,6 +1477,11 @@ skip_countries:
goto alloc_fail8;
}
 
+   if (quirks == CLEAR_HALT_CONDITIONS) {
+   usb_clear_halt(usb_dev, usb_rcvbulkpipe(usb_dev, 
epread-bEndpointAddress));
+   usb_clear_halt(usb_dev, usb_sndbulkpipe(usb_dev, 
epwrite-bEndpointAddress));
+   }
+
return 0;
 alloc_fail8:
if (acm-country_codes) {
@@ -1756,6 +1761,10 @@ static const struct usb_device_id acm_ids[] = {
.driver_info = NO_UNION_NORMAL, /* reports zero length descriptor */
},
 
+   { USB_DEVICE(0x2912, 0x0001), /* ATOL FPrint */
+   .driver_info = CLEAR_HALT_CONDITIONS,
+   },
+
/* Nokia S60 phones expose two ACM channels. The first is
 * a modem and is picked up by the standard AT-command
 * information below. The second is 'vendor-specific' but
diff --git a/drivers/usb/class/cdc-acm.h b/drivers/usb/class/cdc-acm.h
index ffeb3c8..b3b6c9d 100644
--- a/drivers/usb/class/cdc-acm.h
+++ b/drivers/usb/class/cdc-acm.h
@@ -133,3 +133,4 @@ struct acm {
 #define NO_DATA_INTERFACE  BIT(4)
 #define IGNORE_DEVICE  BIT(5)
 #define QUIRK_CONTROL_LINE_STATE   BIT(6)
+#define CLEAR_HALT_CONDITIONS  BIT(7)
-- 
2.4.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 1/1] USB-SERIAL : Changing usb_serial_generic_open prototype

2015-06-02 Thread Johan Hovold 
[ Please avoid top-posting. ]

On Tue, Jun 02, 2015 at 02:49:30PM +0530, Abhishek bist wrote:
 Yes, I gone through this warning. It is because if i want to make this
 compilation warning free
 than i have to change the prototype of a open function pointer
 described in usb_serial_driver
 and changing the prototype over there would affect all the device
 driver lying in usb-serial
 category , which is definitely not recommended.

Exactly. My point was that this change is neither correct or desired.
And that you need to pay attention to any compilation warning that your
changes cause. ;)

   Anyways i got your point .

Johan
--
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] usb: isp1760: fix null dereference if kzalloc returns null

2015-06-02 Thread Sergei Shtylyov 

Hello.

On 06/02/2015 06:41 PM, Laurent Pinchart wrote:


From: Colin Ian King colin.k...@canonical.com



If kzalloc returns null then isp1760_ep_alloc_request performs
a null pointer dereference on req. Check for null to avoid this.



I told you there's no dereference and yet you're repeating it again. :-(



How about



isp1760_ep_alloc_request allocates a structure with kzalloc without checking
for NULL and then returns a pointer to one of the structure fields. As the
field happens to be the first in the structure the caller can properly check
for NULL, but this is risky if the structure layout is changed later. Add an
explicit NULL check for the kzalloc return value.


   Fine with me! Thanks, Laurent. :-)


a null pointer dereference on req. Check for null to avoid this.



Detected with smatch static analysis:



drivers/usb/isp1760/isp1760-udc.c:816 isp1760_ep_alloc_request()



error: potential null dereference 'req'.  (kzalloc returns null)



Signed-off-by: Colin Ian King colin.k...@canonical.com


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 v2 1/6] USB: bcma: remove chip id check

2015-06-02 Thread Hauke Mehrtens 
I have never seen any bcma device with an USB host core which was not a
SoC, the bcma devices have an USB device core with a different core id.
Some SoC have IDs with 47XX and 53XX in decimal form which would be
rejected by this check. Instead of fixing this check just remove it.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/usb/host/bcma-hcd.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c
index 526cfab..976b4e1 100644
--- a/drivers/usb/host/bcma-hcd.c
+++ b/drivers/usb/host/bcma-hcd.c
@@ -214,16 +214,11 @@ err_alloc:
 static int bcma_hcd_probe(struct bcma_device *dev)
 {
int err;
-   u16 chipid_top;
u32 ohci_addr;
struct bcma_hcd_device *usb_dev;
struct bcma_chipinfo *chipinfo;
 
chipinfo = dev-bus-chipinfo;
-   /* USBcores are only connected on embedded devices. */
-   chipid_top = (chipinfo-id  0xFF00);
-   if (chipid_top != 0x4700  chipid_top != 0x5300)
-   return -ENODEV;
 
/* TODO: Probably need checks here; is the core connected? */
 
-- 
2.1.4

--
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 v2 3/6] USB: bcma: use devm_kzalloc

2015-06-02 Thread Hauke Mehrtens 
Instead of manually handling the frees use devm. There was also a free
missing in the unregister call which is not needed with devm.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/usb/host/bcma-hcd.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c
index b4ec4ec..34ab0a4 100644
--- a/drivers/usb/host/bcma-hcd.c
+++ b/drivers/usb/host/bcma-hcd.c
@@ -225,7 +225,8 @@ static int bcma_hcd_probe(struct bcma_device *dev)
if (dma_set_mask_and_coherent(dev-dma_dev, DMA_BIT_MASK(32)))
return -EOPNOTSUPP;
 
-   usb_dev = kzalloc(sizeof(struct bcma_hcd_device), GFP_KERNEL);
+   usb_dev = devm_kzalloc(dev-dev, sizeof(struct bcma_hcd_device),
+  GFP_KERNEL);
if (!usb_dev)
return -ENOMEM;
 
@@ -239,10 +240,8 @@ static int bcma_hcd_probe(struct bcma_device *dev)
ohci_addr = 0x18009000;
 
usb_dev-ohci_dev = bcma_hcd_create_pdev(dev, true, ohci_addr);
-   if (IS_ERR(usb_dev-ohci_dev)) {
-   err = PTR_ERR(usb_dev-ohci_dev);
-   goto err_free_usb_dev;
-   }
+   if (IS_ERR(usb_dev-ohci_dev))
+   return PTR_ERR(usb_dev-ohci_dev);
 
usb_dev-ehci_dev = bcma_hcd_create_pdev(dev, false, dev-addr);
if (IS_ERR(usb_dev-ehci_dev)) {
@@ -255,8 +254,6 @@ static int bcma_hcd_probe(struct bcma_device *dev)
 
 err_unregister_ohci_dev:
platform_device_unregister(usb_dev-ohci_dev);
-err_free_usb_dev:
-   kfree(usb_dev);
return err;
 }
 
-- 
2.1.4

--
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 v2 0/6] USB: bcma: add support for ARM based SoCs

2015-06-02 Thread Hauke Mehrtens 
These patches are fixing minor bugs and are adding support for ARM 
based Broadcom BCM47XX and BCM53XX SoCs.

Changes since:
v1:
 * add patch USB: bcma: fix error handling in bcma_hcd_create_pdev()
 * do not call bcma_core_disable(dev, 0) before enable.

Hauke Mehrtens (6):
  USB: bcma: remove chip id check
  USB: bcma: replace numbers with constants
  USB: bcma: use devm_kzalloc
  USB: bcma: fix error handling in bcma_hcd_create_pdev()
  USB: bcma: add bcm53xx support
  USB: bcma: add support for controlling bus power through GPIO

 drivers/usb/host/bcma-hcd.c | 117 +---
 1 file changed, 99 insertions(+), 18 deletions(-)

-- 
2.1.4

--
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 v2 6/6] USB: bcma: add support for controlling bus power through GPIO

2015-06-02 Thread Hauke Mehrtens 
On some boards a GPIO is needed to activate USB controller. Make it
possible to specify such a GPIO in device tree.

Signed-off-by: Felix Fietkau n...@openwrt.org
Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/usb/host/bcma-hcd.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c
index 9954e32..291b84a 100644
--- a/drivers/usb/host/bcma-hcd.c
+++ b/drivers/usb/host/bcma-hcd.c
@@ -24,6 +24,8 @@
 #include linux/platform_device.h
 #include linux/module.h
 #include linux/slab.h
+#include linux/of.h
+#include linux/of_gpio.h
 #include linux/usb/ehci_pdriver.h
 #include linux/usb/ohci_pdriver.h
 
@@ -209,6 +211,23 @@ static void bcma_hcd_init_chip_arm(struct bcma_device *dev)
iounmap(dmu);
 }
 
+static void bcma_hci_platform_power_gpio(struct bcma_device *dev, bool val)
+{
+   int gpio;
+
+   gpio = of_get_named_gpio(dev-dev.of_node, vcc-gpio, 0);
+   if (!gpio_is_valid(gpio))
+   return;
+
+   if (val) {
+   gpio_request(gpio, bcma-hcd-gpio);
+   gpio_set_value(gpio, 1);
+   } else {
+   gpio_set_value(gpio, 0);
+   gpio_free(gpio);
+   }
+}
+
 static const struct usb_ehci_pdata ehci_pdata = {
 };
 
@@ -295,6 +314,8 @@ static int bcma_hcd_probe(struct bcma_device *dev)
return -ENODEV;
}
 
+   bcma_hci_platform_power_gpio(dev, true);
+
/* In AI chips EHCI is addrspace 0, OHCI is 1 */
ohci_addr = dev-addr_s[0];
if ((chipinfo-id == BCMA_CHIP_ID_BCM5357 ||
@@ -336,6 +357,7 @@ static void bcma_hcd_remove(struct bcma_device *dev)
 
 static void bcma_hcd_shutdown(struct bcma_device *dev)
 {
+   bcma_hci_platform_power_gpio(dev, false);
bcma_core_disable(dev, 0);
 }
 
@@ -343,6 +365,7 @@ static void bcma_hcd_shutdown(struct bcma_device *dev)
 
 static int bcma_hcd_suspend(struct bcma_device *dev)
 {
+   bcma_hci_platform_power_gpio(dev, false);
bcma_core_disable(dev, 0);
 
return 0;
@@ -350,6 +373,7 @@ static int bcma_hcd_suspend(struct bcma_device *dev)
 
 static int bcma_hcd_resume(struct bcma_device *dev)
 {
+   bcma_hci_platform_power_gpio(dev, true);
bcma_core_enable(dev, 0);
 
return 0;
-- 
2.1.4

--
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 v2 5/6] USB: bcma: add bcm53xx support

2015-06-02 Thread Hauke Mehrtens 
The Broadcom ARM SoCs with this usb core need a different
initialization and they have a different core id. This patch adds
support for these USB 2.0 core.

Signed-off-by: Felix Fietkau n...@openwrt.org
Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/usb/host/bcma-hcd.c | 70 +++--
 1 file changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c
index 35d45a9..9954e32 100644
--- a/drivers/usb/host/bcma-hcd.c
+++ b/drivers/usb/host/bcma-hcd.c
@@ -2,7 +2,8 @@
  * Broadcom specific Advanced Microcontroller Bus
  * Broadcom USB-core driver (BCMA bus glue)
  *
- * Copyright 2011-2012 Hauke Mehrtens ha...@hauke-m.de
+ * Copyright 2011-2015 Hauke Mehrtens ha...@hauke-m.de
+ * Copyright 2015 Felix Fietkau n...@openwrt.org
  *
  * Based on ssb-ohci driver
  * Copyright 2007 Michael Buesch m...@bues.ch
@@ -88,7 +89,7 @@ static void bcma_hcd_4716wa(struct bcma_device *dev)
 }
 
 /* based on arch/mips/brcm-boards/bcm947xx/pcibios.c */
-static void bcma_hcd_init_chip(struct bcma_device *dev)
+static void bcma_hcd_init_chip_mips(struct bcma_device *dev)
 {
u32 tmp;
 
@@ -159,6 +160,55 @@ static void bcma_hcd_init_chip(struct bcma_device *dev)
}
 }
 
+static void bcma_hcd_init_chip_arm(struct bcma_device *dev)
+{
+   struct bcma_device *arm_core;
+   void __iomem *dmu;
+   u32 val;
+
+   bcma_core_enable(dev, 0);
+
+   usleep_range(1000, 2000);
+
+   /* Set packet buffer OUT threshold */
+   val = bcma_read32(dev, 0x94);
+   val = 0x;
+   val |= 0x80  16;
+   bcma_write32(dev, 0x94, val);
+
+   /* Enable break memory transfer */
+   val = bcma_read32(dev, 0x9c);
+   val |= 1;
+   bcma_write32(dev, 0x9c, val);
+
+   if (dev-bus-chipinfo.pkg != BCMA_PKG_ID_BCM4707 
+   dev-bus-chipinfo.pkg != BCMA_PKG_ID_BCM4708)
+   return;
+
+   arm_core = bcma_find_core(dev-bus, BCMA_CORE_ARMCA9);
+   if (!arm_core) {
+   dev_err(dev-dev, can not find ARM Cortex A9 ihost core\n);
+   return;
+   }
+
+   dmu = ioremap_nocache(arm_core-addr_s[0], 0x1000);
+   if (!dmu) {
+   dev_err(dev-dev, can not map ARM Cortex A9 ihost core\n);
+   return;
+   }
+
+   /* Unlock DMU PLL settings */
+   iowrite32(0xea68, dmu + 0x180);
+
+   /* Write USB 2.0 PLL control setting */
+   iowrite32(0x00dd10c3, dmu + 0x164);
+
+   /* Lock DMU PLL settings */
+   iowrite32(0x, dmu + 0x180);
+
+   iounmap(dmu);
+}
+
 static const struct usb_ehci_pdata ehci_pdata = {
 };
 
@@ -230,7 +280,20 @@ static int bcma_hcd_probe(struct bcma_device *dev)
if (!usb_dev)
return -ENOMEM;
 
-   bcma_hcd_init_chip(dev);
+   switch (dev-id.id) {
+   case BCMA_CORE_NS_USB20:
+   if (dev-bus-chipinfo.id != BCMA_CHIP_ID_BCM4707 
+   dev-bus-chipinfo.id != BCMA_CHIP_ID_BCM53018)
+   return -ENODEV;
+
+   bcma_hcd_init_chip_arm(dev);
+   break;
+   case BCMA_CORE_USB20_HOST:
+   bcma_hcd_init_chip_mips(dev);
+   break;
+   default:
+   return -ENODEV;
+   }
 
/* In AI chips EHCI is addrspace 0, OHCI is 1 */
ohci_addr = dev-addr_s[0];
@@ -299,6 +362,7 @@ static int bcma_hcd_resume(struct bcma_device *dev)
 
 static const struct bcma_device_id bcma_hcd_table[] = {
BCMA_CORE(BCMA_MANUF_BCM, BCMA_CORE_USB20_HOST, BCMA_ANY_REV, 
BCMA_ANY_CLASS),
+   BCMA_CORE(BCMA_MANUF_BCM, BCMA_CORE_NS_USB20, BCMA_ANY_REV, 
BCMA_ANY_CLASS),
{},
 };
 MODULE_DEVICE_TABLE(bcma, bcma_hcd_table);
-- 
2.1.4

--
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 v2 4/6] USB: bcma: fix error handling in bcma_hcd_create_pdev()

2015-06-02 Thread Hauke Mehrtens 
This patch makes bcma_hcd_create_pdev() not return NULL, but a prober
error code in case of an error.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/usb/host/bcma-hcd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c
index 34ab0a4..35d45a9 100644
--- a/drivers/usb/host/bcma-hcd.c
+++ b/drivers/usb/host/bcma-hcd.c
@@ -169,7 +169,7 @@ static struct platform_device *bcma_hcd_create_pdev(struct 
bcma_device *dev, boo
 {
struct platform_device *hci_dev;
struct resource hci_res[2];
-   int ret = -ENOMEM;
+   int ret;
 
memset(hci_res, 0, sizeof(hci_res));
 
@@ -183,7 +183,7 @@ static struct platform_device *bcma_hcd_create_pdev(struct 
bcma_device *dev, boo
hci_dev = platform_device_alloc(ohci ? ohci-platform :
ehci-platform , 0);
if (!hci_dev)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
hci_dev-dev.parent = dev-dev;
hci_dev-dev.dma_mask = hci_dev-dev.coherent_dma_mask;
-- 
2.1.4

--
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 v2 2/6] USB: bcma: replace numbers with constants

2015-06-02 Thread Hauke Mehrtens 
The constants for these numbers were added long time ago, use them.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/usb/host/bcma-hcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c
index 976b4e1..b4ec4ec 100644
--- a/drivers/usb/host/bcma-hcd.c
+++ b/drivers/usb/host/bcma-hcd.c
@@ -233,7 +233,8 @@ static int bcma_hcd_probe(struct bcma_device *dev)
 
/* In AI chips EHCI is addrspace 0, OHCI is 1 */
ohci_addr = dev-addr_s[0];
-   if ((chipinfo-id == 0x5357 || chipinfo-id == 0x4749)
+   if ((chipinfo-id == BCMA_CHIP_ID_BCM5357 ||
+chipinfo-id == BCMA_CHIP_ID_BCM4749)
 chipinfo-rev == 0)
ohci_addr = 0x18009000;
 
-- 
2.1.4

--
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: integrated bluetooth adapter causes errors in dmesg on boot

2015-06-02 Thread Alan Stern 
On Tue, 2 Jun 2015, Alexander wrote:

 Hello. I have got Asus Z87-Expert motherboard with integrated 
 bluetooth adapter. It causes the following error on boot:
 usb 3-4: string descriptor 0 malformed (err = -61), defaulting to 0x0409

This means the bluetooth adapter sent an invalid string descriptor to
the computer.

 Though there are no real problems with bluetooth, this error is annoying.
 Here is some information:
   dmesg | grep 3-4
 [ 2.037896] usb 3-4: new full-speed USB device number 4 using xhci_hcd
 [ 2.167450] usb 3-4: string descriptor 0 malformed (err = -61), 
 defaulting to 0x0409
 [ 2.169268] usb 3-4: New USB device found, idVendor=0b05, idProduct=17d0
 [ 2.169269] usb 3-4: New USB device strings: Mfr=1, Product=2, 
 SerialNumber=3
   lsusb | grep 0b05
 Bus 003 Device 004: ID 0b05:17d0 ASUSTek Computer, Inc.

Maybe you should complain to the manufacturer.

 If I run lsusb -v in 3.16.0, I get an error
 lsusb: gconv.c:74: __gconv: Assertion `outbuf != ((void *)0)  *outbuf 
 != ((void *)0)' failed.
   just before the information should be displayed about this device.

A bug in lsusb?

 However, if I run 4.0.4, this device changes it's number to 1-4 and 

That's normal; it doesn't mean anything.

 here is information about it:
   lsusb -v
 http://pastebin.com/raw.php?i=veR7PUnb
 dmesg also shows another error with 4.0.4
   usb 1-4: string descriptor 0 read error: -22

Of course, because the device isn't doing what it is supposed to do.

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

[PATCH][V3] usb: isp1760: check for null return from kzalloc

2015-06-02 Thread Colin King 
From: Colin Ian King colin.k...@canonical.com

isp1760_ep_alloc_request allocates a structure with kzalloc without checking 
for NULL and then returns a pointer to one of the structure fields. As the 
field happens to be the first in the structure the caller can properly check 
for NULL, but this is risky if the structure layout is changed later. Add an 
explicit NULL check for the kzalloc return value

Detected with smatch static analysis:

drivers/usb/isp1760/isp1760-udc.c:816 isp1760_ep_alloc_request()
  error: potential null dereference 'req'.  (kzalloc returns null)

[ thanks to Laurent Pinchart for improved commit message ]

Signed-off-by: Colin Ian King colin.k...@canonical.com
---
 drivers/usb/isp1760/isp1760-udc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/isp1760/isp1760-udc.c 
b/drivers/usb/isp1760/isp1760-udc.c
index 3fc4fe7..18ebf5b 100644
--- a/drivers/usb/isp1760/isp1760-udc.c
+++ b/drivers/usb/isp1760/isp1760-udc.c
@@ -812,6 +812,8 @@ static struct usb_request *isp1760_ep_alloc_request(struct 
usb_ep *ep,
struct isp1760_request *req;
 
req = kzalloc(sizeof(*req), gfp_flags);
+   if (!req)
+   return NULL;
 
return req-req;
 }
-- 
2.1.4

--
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 0/6] USB: bcma: add support for ARM based SoCs

2015-06-02 Thread Rafał Miłecki 
On 2 June 2015 at 21:35, Hauke Mehrtens ha...@hauke-m.de wrote:
 These patches are fixing minor bugs and are adding support for ARM
 based Broadcom BCM47XX and BCM53XX SoCs.

 Changes since:
 v1:
  * add patch USB: bcma: fix error handling in bcma_hcd_create_pdev()
  * do not call bcma_core_disable(dev, 0) before enable.

Looks fine for me, thanks for working on this!
--
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: integrated bluetooth adapter causes errors in dmesg on boot

2015-06-02 Thread Greg KH 
On Tue, Jun 02, 2015 at 06:16:20PM +0300, Alexander wrote:
 Hello. I have got Asus Z87-Expert motherboard with integrated bluetooth
 adapter. It causes the following error on boot:
 usb 3-4: string descriptor 0 malformed (err = -61), defaulting to 0x0409
 Though there are no real problems with bluetooth, this error is annoying.
 Here is some information:
  dmesg | grep 3-4
 [ 2.037896] usb 3-4: new full-speed USB device number 4 using xhci_hcd
 [ 2.167450] usb 3-4: string descriptor 0 malformed (err = -61), defaulting
 to 0x0409
 [ 2.169268] usb 3-4: New USB device found, idVendor=0b05, idProduct=17d0
 [ 2.169269] usb 3-4: New USB device strings: Mfr=1, Product=2,
 SerialNumber=3
  lsusb | grep 0b05
 Bus 003 Device 004: ID 0b05:17d0 ASUSTek Computer, Inc.
 If I run lsusb -v in 3.16.0, I get an error
 lsusb: gconv.c:74: __gconv: Assertion `outbuf != ((void *)0)  *outbuf !=
 ((void *)0)' failed.

That's a really odd error, as lsusb doesn't use gconv, neither does
libusb, where does that file (gconv.c) come from?

What version of lsusb are you using?

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][V3] usb: isp1760: check for null return from kzalloc

2015-06-02 Thread Laurent Pinchart 
Hi Colin,

Thank you for the patch.

On Tuesday 02 June 2015 19:05:13 Colin King wrote:
 From: Colin Ian King colin.k...@canonical.com
 
 isp1760_ep_alloc_request allocates a structure with kzalloc without checking
 for NULL and then returns a pointer to one of the structure fields. As the
 field happens to be the first in the structure the caller can properly
 check for NULL, but this is risky if the structure layout is changed later.
 Add an explicit NULL check for the kzalloc return value
 
 Detected with smatch static analysis:
 
 drivers/usb/isp1760/isp1760-udc.c:816 isp1760_ep_alloc_request()
   error: potential null dereference 'req'.  (kzalloc returns null)
 
 [ thanks to Laurent Pinchart for improved commit message ]
 
 Signed-off-by: Colin Ian King colin.k...@canonical.com

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

Felipe, I expect you to pick this up, please let me know if there's any issue.

 ---
  drivers/usb/isp1760/isp1760-udc.c | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/drivers/usb/isp1760/isp1760-udc.c
 b/drivers/usb/isp1760/isp1760-udc.c index 3fc4fe7..18ebf5b 100644
 --- a/drivers/usb/isp1760/isp1760-udc.c
 +++ b/drivers/usb/isp1760/isp1760-udc.c
 @@ -812,6 +812,8 @@ static struct usb_request
 *isp1760_ep_alloc_request(struct usb_ep *ep, struct isp1760_request *req;
 
   req = kzalloc(sizeof(*req), gfp_flags);
 + if (!req)
 + return NULL;
 
   return req-req;
  }

-- 
Regards,

Laurent Pinchart

--
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 00/21] On-demand device registration

2015-06-02 Thread Tomeu Vizoso 
On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote:
 On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:

 have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 This is pretty cool, but a too local solution to a global problem.

 Deferred probe and initcall reordering, silly as they may seem,
 does not require you to use device tree.

 The real solution, which I think I pointed out already when we
 added deferred probe, is to put dependency graphs in the drivers

By this you mean something like what Thierry suggested here?

http://article.gmane.org/gmane.linux.kernel/1774623

 and have the kernel device driver core percolate dependecies by
 walking the graph on probing driver, removing driver (usually the
 inverse use case), [runtime] suspend and [runtime] resumeing
 a driver. Possibly the dependencies will even be different
 depending on use case.

 This is what systemd is doing in userspace for starting services:
 ask for your dependencies and wait for them if they are not
 there. So drivers ask for resources and wait for them. It also
 needs to be abstract, so for example we need to be able to
 hang on regulator_get() until the driver is up and providing that
 regulator, and as long as everything is in slowpath it should
 be OK. (And vice versa mutatis mutandis for clk, gpio, pin
 control, interrupts (!) and DMA channels for example.)

I understood above that you propose probing devices in order, but now
you mention that resource getters would block until the dependency is
fulfilled which confuses me because if we are probing in order then
all dependencies would be fulfilled before the device in question gets
probed.

 So if this should be solved it should be solved in an abstract way
 in the device driver core available for all, then have calls calling
 out to DT, ACPI, possibly even PCI or USB (as these
 enumerate devices themselves) to obtain a certain
 dependency.

Yeah, I was planning looking into this now that I got it working with
async probing.

Thanks,

Tomeu

 Yours,
 Linus Walleij
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 1/2] Bluetooth: Add reset_resume function

2015-06-02 Thread Josh Boyer 
On Mon, Jun 1, 2015 at 9:28 PM, Marcel Holtmann mar...@holtmann.org wrote:
 Hi Laura,

 Bluetooth devices off of some buses such as USB may lose power across
 suspend/resume. When this happens, drivers may need to have the setup
 function called again and behave differently than a cold power on.
 Add a reset_resume function for drivers to call. During the
 reset_resume case, the flag HCI_RESET_RESUME will be set to allow
 drivers to differentate.

 Signed-off-by: Laura Abbott labb...@fedoraproject.org
 ---
 This matches with what hci_reset_dev does and also ensures
 the setup function gets called again.
 ---
 include/net/bluetooth/hci.h  |  1 +
 include/net/bluetooth/hci_core.h |  1 +
 net/bluetooth/hci_core.c | 16 
 3 files changed, 18 insertions(+)

 diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
 index d95da83..6285410 100644
 --- a/include/net/bluetooth/hci.h
 +++ b/include/net/bluetooth/hci.h
 @@ -185,6 +185,7 @@ enum {
   HCI_RAW,

   HCI_RESET,
 + HCI_RESET_RESUME,
 };

 no more addition to this list of flags please. These are userspace exposed 
 flags and with that ABI that we are never ever touching again. If you need 
 flags on a per device basis, then use the second list.

It would be helpful for other developers if you added a comment to
that effect above the enum definition.  Otherwise you're going to wind
up repeating yourself over time.

Also, if they're exposed to userspace, should this file be using the
uapi mechanism?  I'm confused how they're exposed today, given that
they aren't installed via 'make headers_install'.  Is this manually
synced with some other .h file in a userspace package?

josh
--
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 0/2] Remaining sunxi musb patches

2015-06-02 Thread Felipe Balbi 
Hi,

On Tue, Jun 02, 2015 at 09:14:05AM +0200, Hans de Goede wrote:
 Here is an updated version of the remaining (not yet merged in Felipe's
 tree)
 sunxi musb patches.
 
 The phy-sun4i-usb: Add full support for usb0 phy / OTG patch has been
 updated with a small bug-fix and is ready for merging.
 
 The musb: Add support for the Allwinner sunxi musb patch has been
 updated
 to use the latest version of Maxime's sunxi sram controller driver. This
 one has a compile-time dependency on Maxime's sunxi sram controller
 driver,
 so it cannot be merged until that is merged.
 
 
 
 Arnd has just merged the updated sram controller into the next branch
 of the soc-drivers repo, so both these patches are now ready to merge.
 
 all right, so for v4.3 merge window there will be no issues in queues
 the two remaining patches. Thanks
 
 So I take it that it is too late to get these 2 into 4.2 ? I've a bunch
 of (small) follow up patches coming up to enable support for the musb
 controller on new boards, merging those would be easier if these were
 already merged. And there also is a largish set of sunxi dts patches
 actually enabling the musb code which is sorta waiting for merging
 these 2 (waiting for the dt binding to be stable).

DTS should not have to wait. If we know what the compatible should look
like, you can send your DTS upstream no problem. There will just be a
few devices which will not trigger a driver probe, but that's just fine.

 If this is not going to make 4.2, can you and Kishon at least review
 them and let me know of they will get merged for 4.3 as is (baring
 any merge issues) ?

Sure, that I can do, no issues.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] USB: ftdi_sio: add GPIO support

2015-06-02 Thread Linus Walleij 
On Sat, May 30, 2015 at 10:29 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
 On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:

 However is the MFD cell approach acceptable?

 Yes it is.

 Going back to this old conversation... Actually, I disagree. There is
 absolutely no need to go the MFD approach for this driver. That just
 adds layers of abstraction for no purpose. GPIOLIB is an interface,
 and it is completely fine for a driver to hook up to the GPIOLIB
 interface at the same time as exposing a serial port. MFD doesn't buy
 the driver anything useful here.

What is buys is centralizing code into the proper drivers/gpio
folder of the kernel. So more of a maintenance point than a
mechanics/performance point.

We do have GPIO drivers scattered all over the kernel so one
more or less wouldn't matter so much...

Yours,
Linus Walleij
--
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: USB3 external HDD not recognized [regression]

2015-06-02 Thread Mathias Nyman 
Hi

On 29.05.2015 15:35, Ralf Jung wrote:
 Hi again,
 
 Indeed doing echo 'on' | sudo tee /sys/bus/pci/devices/*/power/control
 fixes the problem: When I subsequently plug in the disk, it is
 recognized correctly. I confirmed this with an older kernel (the 3.16
 Debian kernel, to be more precise). That's good to know, now I don't
 need to reboot to a different kernel anymore to do fast backups ;-)
 
 Is there any news on this? Any further information I can provide to help
 fix the issue?
 

I got some untested and not yet reviewed usb3 resume race fixes from Zhuang Jin 
Can
If you can try them out and see if they help it would be great.
They are sitting in a topic branch called xhci_usb3_pm_fixes in my tree:
(5 extra patches on top of current usb-linus)

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git xhci_usb3_pm_fixes

If not, then the we need to change xhci resume code so that we resume the 
roothubs as default
except if we are runtime suspended and woken up just to be (system) suspended.

-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: USB3 external HDD not recognized [regression]

2015-06-02 Thread Ralf Jung 
Hi,

 Indeed doing echo 'on' | sudo tee /sys/bus/pci/devices/*/power/control
 fixes the problem: When I subsequently plug in the disk, it is
 recognized correctly. I confirmed this with an older kernel (the 3.16
 Debian kernel, to be more precise). That's good to know, now I don't
 need to reboot to a different kernel anymore to do fast backups ;-)

 Is there any news on this? Any further information I can provide to help
 fix the issue?

 
 I got some untested and not yet reviewed usb3 resume race fixes from Zhuang 
 Jin Can
 If you can try them out and see if they help it would be great.
 They are sitting in a topic branch called xhci_usb3_pm_fixes in my tree:
 (5 extra patches on top of current usb-linus)
 
 git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
 xhci_usb3_pm_fixes

This is my production and (main and only) work machine. If you tell me
testing that branch is safe and won't mess up my file systems or
hardware, I can give it a try.

Kind regards,
Ralf

 
 If not, then the we need to change xhci resume code so that we resume the 
 roothubs as default
 except if we are runtime suspended and woken up just to be (system) suspended.
 
 -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

[PATCH v3] usb: chipidea: Use extcon framework for VBUS and ID detect

2015-06-02 Thread Ivan T. Ivanov 
On recent Qualcomm platforms VBUS and ID lines are not routed to
USB PHY LINK controller. Use extcon framework to receive connect
and disconnect ID and VBUS notification.

Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
---
Changes sice v2 [1].

* Simulate IRQ on extcon event - used to trigger OTG state machine.

I have to admit that I couldn't test complete Chipidea OTG state machine,
because my setup is little weird. I am using qcom,usb-otg-ci as PHY/OTG
provider, qcom,ehci-host as host controller driver and qcom,ci-hdrc for
device role.

There could be patch conflict regarding ci-hdrc-qcom.txt, because Rob Herring
is consolidating DT binding for all vendors which integrate this device [2]

[1] https://lkml.org/lkml/2015/4/15/283
[2] http://www.spinics.net/lists/linux-usb/msg125453.html

 .../devicetree/bindings/usb/ci-hdrc-qcom.txt   |   9 ++
 drivers/usb/chipidea/Kconfig   |   1 +
 drivers/usb/chipidea/core.c| 125 +
 drivers/usb/chipidea/otg.c |  55 -
 include/linux/usb/chipidea.h   |  24 
 5 files changed, 212 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
index f2899b5..c635aca 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
@@ -7,6 +7,14 @@ Required properties:
 - usb-phy:  phandle for the PHY device
 - dr_mode:  Should be peripheral

+Optional properties:
+- extcon:   phandles to external connector devices. First phandle
+should point to external connector, which provide USB
+cable events, the second should point to external connector
+device, which provide USB-HOST cable events. If one of
+the external connector devices is not required, empty 0
+phandle should be specified.
+
 Examples:
gadget@f9a55000 {
compatible = qcom,ci-hdrc;
@@ -14,4 +22,5 @@ Examples:
dr_mode = peripheral;
interrupts = 0 134 0;
usb-phy = usbphy0;
+   extcon = 0, usb_id;
};
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 5ce3f1d..5619b8c 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -1,6 +1,7 @@
 config USB_CHIPIDEA
tristate ChipIdea Highspeed Dual Role Controller
depends on ((USB_EHCI_HCD  USB_GADGET) || (USB_EHCI_HCD  
!USB_GADGET) || (!USB_EHCI_HCD  USB_GADGET))  HAS_DMA
+   select EXTCON
help
  Say Y here if your system has a dual role high speed USB
  controller based on ChipIdea silicon IP. Currently, only the
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 74fea4f..2ae2c09 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -47,6 +47,7 @@
 #include linux/delay.h
 #include linux/device.h
 #include linux/dma-mapping.h
+#include linux/extcon.h
 #include linux/phy/phy.h
 #include linux/platform_device.h
 #include linux/module.h
@@ -557,9 +558,47 @@ static irqreturn_t ci_irq(int irq, void *data)
return ret;
 }

+static int ci_vbus_notifier(struct notifier_block *nb, unsigned long event,
+   void *ptr)
+{
+   struct ci_hdrc_cable *vbus = container_of(nb, struct ci_hdrc_cable, nb);
+   struct ci_hdrc *ci = vbus-ci;
+
+   if (event)
+   vbus-state = true;
+   else
+   vbus-state = false;
+
+   vbus-changed = true;
+
+   ci_irq(ci-irq, ci);
+   return NOTIFY_DONE;
+}
+
+static int ci_id_notifier(struct notifier_block *nb, unsigned long event,
+ void *ptr)
+{
+   struct ci_hdrc_cable *id = container_of(nb, struct ci_hdrc_cable, nb);
+   struct ci_hdrc *ci = id-ci;
+
+   if (event)
+   id-state = false;
+   else
+   id-state = true;
+
+   id-changed = true;
+
+   ci_irq(ci-irq, ci);
+   return NOTIFY_DONE;
+}
+
 static int ci_get_platdata(struct device *dev,
struct ci_hdrc_platform_data *platdata)
 {
+   struct extcon_dev *ext_vbus, *ext_id;
+   struct ci_hdrc_cable *cable;
+   int ret;
+
if (!platdata-phy_mode)
platdata-phy_mode = of_usb_get_phy_mode(dev-of_node);

@@ -591,9 +630,89 @@ static int ci_get_platdata(struct device *dev,
if (of_usb_get_maximum_speed(dev-of_node) == USB_SPEED_FULL)
platdata-flags |= CI_HDRC_FORCE_FULLSPEED;

+   ext_id = ERR_PTR(-ENODEV);
+   ext_vbus = ERR_PTR(-ENODEV);
+   if (of_property_read_bool(dev-of_node, extcon)) {
+   /* Each one of them is not mandatory */
+   ext_vbus = extcon_get_edev_by_phandle(dev, 0);
+   if (IS_ERR(ext_vbus)  PTR_ERR(ext_vbus) !=

Re: [PATCH v4 1/2] phy-sun4i-usb: Add full support for usb0 phy / OTG

2015-06-02 Thread Maxime Ripard 
Hi,

On Mon, Jun 01, 2015 at 11:28:23AM +0200, Hans de Goede wrote:
 On 01-06-15 11:22, Maxime Ripard wrote:
 On Sun, May 31, 2015 at 06:10:25PM +0200, Hans de Goede wrote:
 +   /* We either want both gpio pins or neither (when in host mode) */
 +   if (!data-id_det_gpio != !data-vbus_det_gpio) {
 +   dev_err(dev, failed to get id or vbus detect pin\n);
 +   return -ENODEV;
 +   }
 
 The fact that the driver expects both to be set if one is should be in
 the binding documentation.
 
 That would be behavior description, and I've always been told that the
 binding should only document the hardware description, not the behavior.

Yes, that's true, but here it looks more like there's no point of
having one without the other.

Pretty much like interrupt-parent and interrupt. A single one doesn't
really make much sense without the other.

And I don't think saying that you would need some additional
properties when in device mode rather than in host mode is really
documenting a behaviour. It does change things at a hardware level
too.

 Also this may change in the future as we add support for more boards,
 e.g. the cubieboard seems to be unable to turn vbus off ever, so vbus-det
 will always read as 1 / high, making it rather useless. This is something
 which I still need to figure out how to deal with.

We can always figure it out in due time.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH 1/2] Bluetooth: Add reset_resume function

2015-06-02 Thread Marcel Holtmann 
Hi Josh,

 Bluetooth devices off of some buses such as USB may lose power across
 suspend/resume. When this happens, drivers may need to have the setup
 function called again and behave differently than a cold power on.
 Add a reset_resume function for drivers to call. During the
 reset_resume case, the flag HCI_RESET_RESUME will be set to allow
 drivers to differentate.
 
 Signed-off-by: Laura Abbott labb...@fedoraproject.org
 ---
 This matches with what hci_reset_dev does and also ensures
 the setup function gets called again.
 ---
 include/net/bluetooth/hci.h  |  1 +
 include/net/bluetooth/hci_core.h |  1 +
 net/bluetooth/hci_core.c | 16 
 3 files changed, 18 insertions(+)
 
 diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
 index d95da83..6285410 100644
 --- a/include/net/bluetooth/hci.h
 +++ b/include/net/bluetooth/hci.h
 @@ -185,6 +185,7 @@ enum {
  HCI_RAW,
 
  HCI_RESET,
 + HCI_RESET_RESUME,
 };
 
 no more addition to this list of flags please. These are userspace exposed 
 flags and with that ABI that we are never ever touching again. If you need 
 flags on a per device basis, then use the second list.
 
 It would be helpful for other developers if you added a comment to
 that effect above the enum definition.  Otherwise you're going to wind
 up repeating yourself over time.

nobody has done that so far ;)

 Also, if they're exposed to userspace, should this file be using the
 uapi mechanism?  I'm confused how they're exposed today, given that
 they aren't installed via 'make headers_install'.  Is this manually
 synced with some other .h file in a userspace package?

This code is from 2.4.6 and with that pretty much ancient and predates UAPI. 
The BlueZ userspace library provides userspace versions of these defines etc.

Regards

Marcel

--
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/2] musb: Add support for the Allwinner sunxi musb controller

2015-06-02 Thread Felipe Balbi 
On Sun, May 31, 2015 at 06:10:26PM +0200, Hans de Goede wrote:
 This is based on initial code to get the Allwinner sunxi musb controller
 supported by Chen-Yu Tsai and Roman Byshko.
 
 This adds support for the Allwinner sunxi musb controller in both host only
 and otg mode. Peripheral only mode is not supported, as no boards use that.
 
 This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
 (A13 SoC) with a variety of devices in host mode and with the g_serial gadget
 driver in peripheral mode, plugging otg / host cables in/out a lot of times
 in all possible imaginable plug orders.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com

this looks good, I'd say it's ready for v4.3

-- 
balbi


signature.asc
Description: Digital signature

integrated bluetooth adapter causes errors in dmesg on boot

2015-06-02 Thread Alexander 
Hello. I have got Asus Z87-Expert motherboard with integrated 
bluetooth adapter. It causes the following error on boot:

usb 3-4: string descriptor 0 malformed (err = -61), defaulting to 0x0409
Though there are no real problems with bluetooth, this error is annoying.
Here is some information:
 dmesg | grep 3-4
[ 2.037896] usb 3-4: new full-speed USB device number 4 using xhci_hcd
[ 2.167450] usb 3-4: string descriptor 0 malformed (err = -61), 
defaulting to 0x0409

[ 2.169268] usb 3-4: New USB device found, idVendor=0b05, idProduct=17d0
[ 2.169269] usb 3-4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

 lsusb | grep 0b05
Bus 003 Device 004: ID 0b05:17d0 ASUSTek Computer, Inc.
If I run lsusb -v in 3.16.0, I get an error
lsusb: gconv.c:74: __gconv: Assertion `outbuf != ((void *)0)  *outbuf 
!= ((void *)0)' failed.

 just before the information should be displayed about this device.
However, if I run 4.0.4, this device changes it's number to 1-4 and 
here is information about it:

 lsusb -v
http://pastebin.com/raw.php?i=veR7PUnb
dmesg also shows another error with 4.0.4
 usb 1-4: string descriptor 0 read error: -22
--
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] usb: isp1760: fix null dereference if kzalloc returns null

2015-06-02 Thread Laurent Pinchart 
On Monday 01 June 2015 16:51:30 Sergei Shtylyov wrote:
 Hello.
 
 On 6/1/2015 1:43 AM, Colin King wrote:
  From: Colin Ian King colin.k...@canonical.com
  
  If kzalloc returns null then isp1760_ep_alloc_request performs
  a null pointer dereference on req. Check for null to avoid this.
 
 I told you there's no dereference and yet you're repeating it again. :-(

How about

isp1760_ep_alloc_request allocates a structure with kzalloc without checking 
for NULL and then returns a pointer to one of the structure fields. As the 
field happens to be the first in the structure the caller can properly check 
for NULL, but this is risky if the structure layout is changed later. Add an 
explicit NULL check for the kzalloc return value.

  a null pointer dereference on req. Check for null to avoid this.
 
  Detected with smatch static analysis:
  
  drivers/usb/isp1760/isp1760-udc.c:816 isp1760_ep_alloc_request()
  
 error: potential null dereference 'req'.  (kzalloc returns null)
  
  Signed-off-by: Colin Ian King colin.k...@canonical.com

-- 
Regards,

Laurent Pinchart

--
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