date:20170530

Re: [PATCH 6/7] thermal: max77620: fix device-node reference imbalance

2017-05-30 Thread Tyrel Datwyler

On 05/30/2017 09:25 AM, Johan Hovold wrote:
> The thermal child device reuses the parent MFD-device device-tree node
> when registering a thermal zone, but did not take a reference to the
> node.
> 
> This leads to a reference imbalance, and potential use-after-free, when
> the node reference is dropped by the platform-bus device destructor
> (once for the child and later again for the parent).
> 
> Fix this by dropping any reference already held to a device-tree node
> and getting a reference to the parent's node which will be balanced on
> reprobe or on platform-device release, whichever comes first.
> 
> Note that simply clearing the of_node pointer on probe errors and on
> driver unbind would not allow the use of device-managed resources as
> specifically thermal_zone_of_sensor_unregister() claims that a valid
> device-tree node pointer is needed during deregistration (even if it
> currently does not seem to use it).
> 
> Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting 
> junction temp")
> Cc: stable  # 4.9
> Cc: Laxman Dewangan 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/thermal/max77620_thermal.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/max77620_thermal.c 
> b/drivers/thermal/max77620_thermal.c
> index e9a1fe342760..71d35f3c9215 100644
> --- a/drivers/thermal/max77620_thermal.c
> +++ b/drivers/thermal/max77620_thermal.c
> @@ -104,8 +104,6 @@ static int max77620_thermal_probe(struct platform_device 
> *pdev)
>   return -EINVAL;
>   }
>  
> - pdev->dev.of_node = pdev->dev.parent->of_node;
> -
>   mtherm->dev = >dev;
>   mtherm->rmap = dev_get_regmap(pdev->dev.parent, NULL);
>   if (!mtherm->rmap) {
> @@ -113,6 +111,14 @@ static int max77620_thermal_probe(struct platform_device 
> *pdev)
>   return -ENODEV;
>   }
>  
> + /*
> +  * Drop any current reference to a device-tree node and get a
> +  * reference to the parent's node which will be balanced on reprobe or
> +  * on platform-device release.
> +  */
> + of_node_put(pdev->dev.of_node);
> + pdev->dev.of_node = of_node_get(pdev->dev.parent->of_node);
> +

This seems like needless churn. Can't this just be squashed into patch #7?

-Tyrel

>   mtherm->tz_device = devm_thermal_zone_of_sensor_register(>dev, 0,
>   mtherm, _thermal_ops);
>   if (IS_ERR(mtherm->tz_device)) {
> 

--
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/7] USB: core: fix device node leak

2017-05-30 Thread Tyrel Datwyler

On 05/30/2017 09:25 AM, Johan Hovold wrote:
> Make sure to release any OF device-node reference taken when creating
> the USB device.
> 
> Note that we currently do not hold a reference to the root hub
> device-tree node (i.e. the parent controller node).
> 
> Fixes: 69bec7259853 ("USB: core: let USB device know device node")
> Cc: stable    # v4.6
> Cc: Peter Chen 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/core/usb.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> index 28b053cacc90..62e1906bb2f3 100644
> --- a/drivers/usb/core/usb.c
> +++ b/drivers/usb/core/usb.c
> @@ -416,6 +416,8 @@ static void usb_release_dev(struct device *dev)
>  
>   usb_destroy_configuration(udev);
>   usb_release_bos_descriptor(udev);
> + if (udev->parent)
> + of_node_put(dev->of_node);

If I'm following the root hub doesn't hold an of_node reference, so does that 
guarantee
that dev->of_node is NULL for the root hub? If so of_node_put() is safely 
called with a
NULL reference, making the if(udev->parent) unnecessary, and further no need to 
remove it
in follow-up patch #5.

-Tyrel

>   usb_put_hcd(hcd);
>   kfree(udev->product);
>   kfree(udev->manufacturer);
> 

--
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/7] driver core: add helper to reuse a device-tree node

2017-05-30 Thread kbuild test robot

Hi Johan,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.12-rc3 next-20170530]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Johan-Hovold/driver-core-USB-thermal-fix-device-tree-node-reuse/20170531-043026
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id'
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id'
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
>> include/linux/device.h:970: warning: No description found for parameter 
>> 'of_node_reused'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:971: warning: No description found for parameter 
'dma_ops'
   include/linux/device.h:971: warning: No description found for parameter 
'of_node_reused'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_zlp_not_supp'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:524: warning: No

Re: [v2 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM

2017-05-30 Thread Rob Herring

On Sat, May 20, 2017 at 02:24:56PM +0700, Thang Q. Nguyen wrote:
> XHCI specification 1.1 does not require xHCI 1.0 compliant controllers
> to always enable hardware USB2 LPM.
> However, the current xHCI driver always enable it by setting HLE=1 when
> seeing HLC=1. This makes certain xHCI controllers that have broken USB2
> HW LPM fail to work as there is no way to disable this feature.
> This patch adds support to control disabling USB2 Hardware LPM via
> DT/ACPI attribute.
> 
> Signed-off-by: Tung Nguyen 
> Signed-off-by: Thang Q. Nguyen 
> ---
> Changes since v1:
>  - Update DT/ACPI attribute and corresponding codes from HLE to LPM to
>   be consistent with other attribute names.
> ---
>  Documentation/devicetree/bindings/usb/usb-xhci.txt |1 +

Acked-by: Rob Herring 

>  drivers/usb/host/xhci-plat.c   |3 +++
>  drivers/usb/host/xhci.c|7 ++-
>  drivers/usb/host/xhci.h|1 +
>  4 files changed, 11 insertions(+), 1 deletions(-)
--
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

Dear Email User,

2017-05-30 Thread Mr. Jim David

Dear Email User,
 
Your email address has been selected as one of our lucky winners to receive a 
cash award of One Million United States Dollar from Google incorporated here in 
Istanbul Turkey. For more details, do write back.
Powered By Google Inc.
 
Mr.Jim David
--
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 4/7] driver core: fix automatic pinctrl management

2017-05-30 Thread Linus Walleij

On Tue, May 30, 2017 at 6:25 PM, Johan Hovold  wrote:

> Commit ab78029ecc34 ("drivers/pinctrl: grab default handles from device
> core") added automatic pin-control management to driver core by looking
> up and setting any default pinctrl state found in device tree while a
> device is being probed.

Actually we do not just support device tree, but also passing pin control
states from board files. It is handled by the core all the same.
So it's not a device tree thing.

One of those days we will have ACPI passing state tables too...

But I understand what you mean.

> Fix this by checking the new of_node_reused flag and skipping automatic
> pinctrl configuration during probe if set.

Seems like a solid idea. I hope we don't need another quirk for ACPI.
Acked-by: Linus Walleij 

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 v8 2/5] usb: early: add driver for xhci debug capability

2017-05-30 Thread Lu Baolu

Hi,

On 05/30/2017 09:46 PM, Vlastimil Babka wrote:
> On 03/21/2017 09:01 AM, Lu Baolu wrote:
>> XHCI debug capability (DbC) is an optional but standalone
>> functionality provided by an xHCI host controller. Software
>> learns this capability by walking through the extended
>> capability list of the host. XHCI specification describes
>> DbC in the section 7.6.
>>
>> This patch introduces the code to probe and initialize the
>> debug capability hardware during early boot. With hardware
>> initialized, the debug target (system on which this code is
>> running) will present a debug device through the debug port
>> (normally the first USB3 port). The debug device is fully
>> compliant with the USB framework and provides the equivalent
>> of a very high performance (USB3) full-duplex serial link
>> between the debug host and target. The DbC functionality is
>> independent of the xHCI host. There isn't any precondition
>> from the xHCI host side for the DbC to work.
>>
>> One use for this feature is kernel debugging, for example
>> when your machine crashes very early before the regular
>> console code is initialized. Other uses include simpler,
>> lockless logging instead of a full-blown printk console
>> driver and klogd.
>>
>> Cc: Ingo Molnar 
>> Cc: Mathias Nyman 
>> Signed-off-by: Lu Baolu 
> ...
>
>> +
>> +#define XDBC_TRACE
>> +#ifdef XDBC_TRACE
>> +#define xdbc_trace  trace_printk
> Did you forget to remove the #define XDBC_TRACE?
>
> Enabling this driver brings the "trace_printk() being used. Allocating
> extra memory. This means that this is a DEBUG kernel and it is unsafe
> for production use." message in 4.12-rcX dmesg.

This feature is only for a DEBUG kernel, should not be enabled for
any production kernel. This was the reason I enabled trace_printk()
by default.

Best regards,
Lu Baolu

> Thanks,
> Vlastimil
>

--
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] gadget: Fix a sleep-in-atomic bug

2017-05-30 Thread Jia-Ju Bai

The driver may sleep under a spin lock, and the function call path is:
ffs_epfile_io (acquire the lock by spin_lock_irq)
  usb_ep_alloc_request(GFP_KERNEL) --> may sleep

To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".

Signed-off-by: Jia-Ju Bai 
---
 drivers/usb/gadget/function/f_fs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 47dda34..be90e25 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1015,7 +1015,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct 
ffs_io_data *io_data)
else
ret = ep->status;
goto error_mutex;
-   } else if (!(req = usb_ep_alloc_request(ep->ep, GFP_KERNEL))) {
+   } else if (!(req = usb_ep_alloc_request(ep->ep, GFP_ATOMIC))) {
ret = -ENOMEM;
} else {
req->buf  = data;
-- 
1.7.9.5


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

[EXAMPLE V4 3/2] ARM: BCM53573: Specify ports for USB LED for Tenda AC9

2017-05-30 Thread Rafał Miłecki

From: Rafał Miłecki 

Signed-off-by: Rafał Miłecki 
---
This patch *should not* be applied. It's only an EXAMPLE and that's why it uses
that weird 3/2 number.

It's a proof of concept, it was tested & will be submitted through ARM tree if
previous patches get accepted.

V3: Switch to the new binding
---
 arch/arm/boot/dts/bcm47189-tenda-ac9.dts | 1 +
 arch/arm/boot/dts/bcm53573.dtsi  | 4 
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/bcm47189-tenda-ac9.dts 
b/arch/arm/boot/dts/bcm47189-tenda-ac9.dts
index 34417dac1cd0..ee44dec7d7ec 100644
--- a/arch/arm/boot/dts/bcm47189-tenda-ac9.dts
+++ b/arch/arm/boot/dts/bcm47189-tenda-ac9.dts
@@ -26,6 +26,7 @@
usb {
label = "bcm53xx:blue:usb";
gpios = < 1 GPIO_ACTIVE_HIGH>;
+   trigger-sources = <_port1>, <_port1>;
};
 
wps {
diff --git a/arch/arm/boot/dts/bcm53573.dtsi b/arch/arm/boot/dts/bcm53573.dtsi
index eae623f76401..5c0b9b4d679a 100644
--- a/arch/arm/boot/dts/bcm53573.dtsi
+++ b/arch/arm/boot/dts/bcm53573.dtsi
@@ -138,10 +138,12 @@
 
ehci_port1: port@1 {
reg = <1>;
+   #source-cells = <0>;
};
 
ehci_port2: port@2 {
reg = <2>;
+   #source-cells = <0>;
};
};
 
@@ -158,10 +160,12 @@
 
ohci_port1: port@1 {
reg = <1>;
+   #source-cells = <0>;
};
 
ohci_port2: port@2 {
reg = <2>;
+   #source-cells = <0>;
};
};
};
-- 
2.11.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 V4 0/2] usb: introduce "trigger-sources" DT property for usbport trigger

2017-05-30 Thread Rafał Miłecki

From: Rafał Miłecki 

This patchset (V4) differs by only a tiny fix in 1/2 changing property used
in the DT example.

I'd epxect both patches to go through Greg's usb.git if accepted.

For a reference (and before someome comes with already rejected solution) see
below history of this work:

1) [PATCH V2] leds: trigger: Introduce an USB port trigger
My initial try of adding "usb-ports" property. Rob said it should be more
generic.

2) [PATCH 1/2] dt-bindings: leds: document new usb-ports property
Rob still didn't like it due to being USB specific.

3) [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property
Jacek didn't like it's more generic than what Linux can already support. Later
we agreed (?) that Linux limitations shouldn't influence DT structure.
Jacek still wanted a specific trigger but Rob said he won't accept something
specific to the USB.
Jacek suggested "trigger-sources" and Rob agreed on the name.
Jacek suggested trying triggers as separated nodes.

4) [PATCH 1/4] dt-bindings: leds: document property for LED triggers
This patch was trying to use separated nodes for triggers, e.g.:
foo-trigger { trigger-type = "foo"; };
Rob didn't like this extra level of indirection. He said Linux drivers shouldn't
define/influence the binding.

So finally I came with this patchset. It doesn't try to use separated nodes for
triggers anymore and it uses the name that was mostly accepted I think. It
should be generic and not influenced by Linux design.

Rafał Miłecki (3):
  dt-bindings: leds: document new trigger-sources property
  usb: core: read USB ports from DT in the usbport LED trigger driver
  ARM: BCM53573: Specify ports for USB LED for Tenda AC9

 Documentation/devicetree/bindings/leds/common.txt | 18 
 arch/arm/boot/dts/bcm47189-tenda-ac9.dts  |  1 +
 arch/arm/boot/dts/bcm53573.dtsi   |  4 ++
 drivers/usb/core/ledtrig-usbport.c| 55 +++
 4 files changed, 78 insertions(+)

-- 
2.11.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 V4 2/2] usb: core: read USB ports from DT in the usbport LED trigger driver

2017-05-30 Thread Rafał Miłecki

From: Rafał Miłecki 

This uses DT info to read relation description of LEDs and USB ports. If
DT has properly described LEDs, trigger will know when to turn them on.

Signed-off-by: Rafał Miłecki 
---
V2: Update to use "led-triggers"
V3: Update to use "trigger-sources"
---
 drivers/usb/core/ledtrig-usbport.c | 55 ++
 1 file changed, 55 insertions(+)

diff --git a/drivers/usb/core/ledtrig-usbport.c 
b/drivers/usb/core/ledtrig-usbport.c
index 1713248ab15a..29c9202226bf 100644
--- a/drivers/usb/core/ledtrig-usbport.c
+++ b/drivers/usb/core/ledtrig-usbport.c
@@ -11,8 +11,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 struct usbport_trig_data {
struct led_classdev *led_cdev;
@@ -123,6 +125,56 @@ static const struct attribute_group ports_group = {
  * Adding & removing ports
  ***/
 
+/**
+ * usbport_trig_port_observed - Check if port should be observed
+ */
+static bool usbport_trig_port_observed(struct usbport_trig_data *usbport_data,
+  struct usb_device *usb_dev, int port1)
+{
+   struct device *dev = usbport_data->led_cdev->dev;
+   struct device_node *led_np = dev->of_node;
+   struct of_phandle_args args;
+   struct device_node *port_np;
+   int count, i;
+
+   if (!led_np)
+   return false;
+
+   /* Get node of port being added */
+   port_np = usb_of_get_child_node(usb_dev->dev.of_node, port1);
+   if (!port_np)
+   return false;
+
+   /* Amount of trigger sources for this LED */
+   count = of_count_phandle_with_args(led_np, "trigger-sources",
+  "#source-cells");
+   if (count < 0) {
+   dev_warn(dev, "Failed to get trigger sources for %s\n",
+led_np->full_name);
+   return false;
+   }
+
+   /* Check list of sources for this specific port */
+   for (i = 0; i < count; i++) {
+   int err;
+
+   err = of_parse_phandle_with_args(led_np, "trigger-sources",
+"#source-cells", i, );
+   if (err) {
+   dev_err(dev, "Failed to get trigger source phandle at 
index %d: %d\n",
+   i, err);
+   continue;
+   }
+
+   of_node_put(args.np);
+
+   if (args.np == port_np)
+   return true;
+   }
+
+   return false;
+}
+
 static int usbport_trig_add_port(struct usbport_trig_data *usbport_data,
 struct usb_device *usb_dev,
 const char *hub_name, int portnum)
@@ -141,6 +193,8 @@ static int usbport_trig_add_port(struct usbport_trig_data 
*usbport_data,
port->data = usbport_data;
port->hub = usb_dev;
port->portnum = portnum;
+   port->observed = usbport_trig_port_observed(usbport_data, usb_dev,
+   portnum);
 
len = strlen(hub_name) + 8;
port->port_name = kzalloc(len, GFP_KERNEL);
@@ -255,6 +309,7 @@ static void usbport_trig_activate(struct led_classdev 
*led_cdev)
if (err)
goto err_free;
usb_for_each_dev(usbport_data, usbport_trig_add_usb_dev_ports);
+   usbport_trig_update_count(usbport_data);
 
/* Notifications */
usbport_data->nb.notifier_call = usbport_trig_notify,
-- 
2.11.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 V4 1/2] dt-bindings: leds: document new trigger-sources property

2017-05-30 Thread Rafał Miłecki

From: Rafał Miłecki 

Some LEDs can be related to a specific device(s) described in the DT.
This property allows specifying such relations. E.g. USB LED should
usually be used to indicate some USB port(s) state.

Please note this binding is designed to be generic and not influenced by
any operating system design. Linux developers may find "trigger" part a
bit confusing since in Linux triggers are separated drivers. It
shouldn't define the binding though (we shouldn't add an extra level of
indirection).

Signed-off-by: Rafał Miłecki 
---
V2: Replace "usb-ports" with "led-triggers" property which is more generic and
allows specifying other devices as well.
V3: Use "trigger-sources" which is even more accurate as devices aren't
precisely triggers.
V4: Update example to use the correct property
---
 Documentation/devicetree/bindings/leds/common.txt | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index 24b656014089..7efaa2cff624 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -49,6 +49,19 @@ Optional properties for child nodes:
 - panic-indicator : This property specifies that the LED should be used,
if at all possible, as a panic indicator.
 
+- trigger-sources : List of devices which should be used as a source triggering
+   this LED activity. Some LEDs can be related to a specific
+   device and should somehow indicate its state. E.g. USB 2.0
+   LED may react to device(s) in a USB 2.0 port(s).
+   Another common example is switch or router with multiple
+   Ethernet ports each of them having its own LED assigned
+   (assuming they are not hardwired). In such cases this
+   property should contain phandle(s) of related source
+   device(s).
+   In many cases LED can be related to more than one device
+   (e.g. one USB LED vs. multiple USB ports) so a list of
+   sources can be specified.
+
 Required properties for flash LED child nodes:
 - flash-max-microamp : Maximum flash LED supply current in microamperes.
 - flash-max-timeout-us : Maximum timeout in microseconds after which the flash
@@ -69,6 +82,11 @@ gpio-leds {
linux,default-trigger = "heartbeat";
gpios = < 0 GPIO_ACTIVE_HIGH>;
};
+
+   usb {
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   trigger-sources = <_port1>, <_port1>;
+   };
 };
 
 max77693-led {
-- 
2.11.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: Kernel / USB bug

2017-05-30 Thread Mathias Nyman


On 29.05.2017 19:50, Nicolas Repentin wrote:

Hi

I doesn't works for me.

Device is Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. /
JMicron USA Technology Corp.

Always got this when plugged:

[  211.577287] xhci_hcd :00:14.0: ERROR Transfer event for disabled
endpoint or incorrect stream ring
[  211.577317] xhci_hcd :00:14.0:  @c490 
 0400 07088000



Even if using storage instead of UAS works around this issue I would be
interested in looking at this in more detail.

This is the second similar case reported to the list.

@@c490 = address of this event (irrelevant)
  = address of transfer TRB this event refers to,  clearly 
wrong!
0400 = completion code = USB Transcation error
07088000 = TRB type(Tranfer event) Slot ID (7) EP id (8),

xhci driver bails out because the address to the TRB causing the error
is zero, need to check spec details if it's legal to have a transfer event
indicating a transfer error but not pointing to a specific transfer.

Any chance you could take xhci traces with a 4.11 kernel or later when this is 
triggered?

1. echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
2. trigger the error
3. send me /sys/kernel/debug/tracing/trace

Thanks
-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: [RESEND PATCH v5] ARM: dts: da850: Add the CPPI 4.1 DMA to the USB OTG controller

2017-05-30 Thread Sekhar Nori

On Thursday 25 May 2017 02:41 PM, Sekhar Nori wrote:
> On Friday 19 May 2017 07:03 PM, Alexandre Bailon wrote:
>> This adds the CPPI 4.1 DMA controller to the USB OTG controller.
>>
>> Changes since v2:
>> - Fixed the the property reg-names (had glue register defined)
>> - Removed few useless property
>>
>> Signed-off-by: Alexandre Bailon 
> 
> Looks good to me. Will wait some more time for other feedback before
> applying.

Applied to v4.13/dt

Thanks,
Sekhar
--
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 v4 9/9] usb: typec: typec_wcove: Use charger irq chip to get usbc virq

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

Currently, in Whiskey cove PMIC driver, USBC IRQ is moved under charger
level2 irq chip. So use irq_chip_data_chgr to get the USBC virtual IRQ
number.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/usb/typec/typec_wcove.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Changes since v3:
 * Added typec fix.

diff --git a/drivers/usb/typec/typec_wcove.c b/drivers/usb/typec/typec_wcove.c
index d5a7b21..00a4bd2 100644
--- a/drivers/usb/typec/typec_wcove.c
+++ b/drivers/usb/typec/typec_wcove.c
@@ -303,7 +303,7 @@ static int wcove_typec_probe(struct platform_device *pdev)
wcove->dev = >dev;
wcove->regmap = pmic->regmap;
 
-   ret = regmap_irq_get_virq(pmic->irq_chip_data_level2,
+   ret = regmap_irq_get_virq(pmic->irq_chip_data_chgr,
  platform_get_irq(pdev, 0));
if (ret < 0)
return ret;
-- 
2.7.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 v4 2/9] mfd: intel_soc_pmic_bxtwc: remove thermal second level irqs

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

Since all second level thermal irqs are consumed by the same
device(bxt_wcove_thermal), there is no need to expose them as separate
interrupts. We can just export only the first level irqs for thermal and
let the device(bxt_wcove_thermal) driver handle the second level irqs
based on thermal interrupt status register. Also, just using only the
first level irq will eliminate the bug involved in requesting only the
second level irq and not explicitly enable the first level irq. For
more info on this issue please read the details at,

https://lkml.org/lkml/2017/2/27/148

Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-for-MFD-by: Lee Jones 
---
 drivers/mfd/intel_soc_pmic_bxtwc.c | 32 
 1 file changed, 12 insertions(+), 20 deletions(-)

Changes since v1:
 * None

Changes since v2: 
 * Rebased on top of latest release.

Changes since v3:
 * Rebased on top of latest release.

diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index 7cbaf1e..7c1ed27 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -84,10 +84,7 @@ enum bxtwc_irqs {
 
 enum bxtwc_irqs_level2 {
/* Level 2 */
-   BXTWC_THRM0_IRQ = 0,
-   BXTWC_THRM1_IRQ,
-   BXTWC_THRM2_IRQ,
-   BXTWC_BCU_IRQ,
+   BXTWC_BCU_IRQ = 0,
BXTWC_ADC_IRQ,
BXTWC_USBC_IRQ,
BXTWC_CHGR0_IRQ,
@@ -114,17 +111,14 @@ static const struct regmap_irq bxtwc_regmap_irqs[] = {
 };
 
 static const struct regmap_irq bxtwc_regmap_irqs_level2[] = {
-   REGMAP_IRQ_REG(BXTWC_THRM0_IRQ, 0, 0xff),
-   REGMAP_IRQ_REG(BXTWC_THRM1_IRQ, 1, 0xbf),
-   REGMAP_IRQ_REG(BXTWC_THRM2_IRQ, 2, 0xff),
-   REGMAP_IRQ_REG(BXTWC_BCU_IRQ, 3, 0x1f),
-   REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 4, 0xff),
-   REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 5, BIT(5)),
-   REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 5, 0x1f),
-   REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 6, 0x1f),
-   REGMAP_IRQ_REG(BXTWC_GPIO0_IRQ, 7, 0xff),
-   REGMAP_IRQ_REG(BXTWC_GPIO1_IRQ, 8, 0x3f),
-   REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 9, 0x03),
+   REGMAP_IRQ_REG(BXTWC_BCU_IRQ, 0, 0x1f),
+   REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 1, 0xff),
+   REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 2, BIT(5)),
+   REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 2, 0x1f),
+   REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 3, 0x1f),
+   REGMAP_IRQ_REG(BXTWC_GPIO0_IRQ, 4, 0xff),
+   REGMAP_IRQ_REG(BXTWC_GPIO1_IRQ, 5, 0x3f),
+   REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 6, 0x03),
 };
 
 static const struct regmap_irq bxtwc_regmap_irqs_tmu[] = {
@@ -142,8 +136,8 @@ static struct regmap_irq_chip bxtwc_regmap_irq_chip = {
 
 static struct regmap_irq_chip bxtwc_regmap_irq_chip_level2 = {
.name = "bxtwc_irq_chip_level2",
-   .status_base = BXTWC_THRM0IRQ,
-   .mask_base = BXTWC_MTHRM0IRQ,
+   .status_base = BXTWC_BCUIRQ,
+   .mask_base = BXTWC_MBCUIRQ,
.irqs = bxtwc_regmap_irqs_level2,
.num_irqs = ARRAY_SIZE(bxtwc_regmap_irqs_level2),
.num_regs = 10,
@@ -177,9 +171,7 @@ static struct resource charger_resources[] = {
 };
 
 static struct resource thermal_resources[] = {
-   DEFINE_RES_IRQ(BXTWC_THRM0_IRQ),
-   DEFINE_RES_IRQ(BXTWC_THRM1_IRQ),
-   DEFINE_RES_IRQ(BXTWC_THRM2_IRQ),
+   DEFINE_RES_IRQ(BXTWC_THRM_LVL1_IRQ),
 };
 
 static struct resource bcu_resources[] = {
-- 
2.7.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 v4 1/9] mfd: intel_soc_pmic_bxtwc: fix TMU interrupt index

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

TMU interrupts are registered as a separate interrupt chip, and
hence it should start its interrupt index(BXTWC_TMU_IRQ) number
from 0. But currently, BXTWC_TMU_IRQ is defined as part of enum
bxtwc_irqs_level2 and its index value is 11. Since this index
value is used when calculating .num_irqs of regmap_irq_chip_tmu,
it incorrectly reports number of irqs as 12 instead of actual
value of 1.

This patch fixes this issue by creating new enum of tmu irqs and
resetting its starting index to 0.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-for-MFD-by: Lee Jones 
---
 drivers/mfd/intel_soc_pmic_bxtwc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

Changes since v1: 
 * Removed code from commit message.

Changes since v2: 
 * Rebased on top of latest release.

Changes sinve v3:
 * Rebased on top of latest release.

diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index 8c3cbf6..7cbaf1e 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -95,7 +95,10 @@ enum bxtwc_irqs_level2 {
BXTWC_GPIO0_IRQ,
BXTWC_GPIO1_IRQ,
BXTWC_CRIT_IRQ,
-   BXTWC_TMU_IRQ,
+};
+
+enum bxtwc_irqs_tmu {
+   BXTWC_TMU_IRQ = 0,
 };
 
 static const struct regmap_irq bxtwc_regmap_irqs[] = {
-- 
2.7.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 v4 6/9] mfd: intel_soc_pmic_bxtwc: utilize devm_* functions in driver probe

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

Cleanup the resource allocation/free code in probe function by using
devm_* calls.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-for-MFD-by: Lee Jones 
---
 drivers/mfd/intel_soc_pmic_bxtwc.c | 54 +-
 1 file changed, 18 insertions(+), 36 deletions(-)

Changes since v1:
 * None

Changes since v2:
 * Rebased on top of latest release.

Changes since v3:
 * None

diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index af11c43..feeda6e 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -399,45 +399,44 @@ static int bxtwc_probe(struct platform_device *pdev)
return ret;
}
 
-   ret = regmap_add_irq_chip(pmic->regmap, pmic->irq,
- IRQF_ONESHOT | IRQF_SHARED,
- 0, _regmap_irq_chip,
- >irq_chip_data);
+   ret = devm_regmap_add_irq_chip(>dev, pmic->regmap, pmic->irq,
+  IRQF_ONESHOT | IRQF_SHARED,
+  0, _regmap_irq_chip,
+  >irq_chip_data);
if (ret) {
dev_err(>dev, "Failed to add IRQ chip\n");
return ret;
}
 
-   ret = regmap_add_irq_chip(pmic->regmap, pmic->irq,
- IRQF_ONESHOT | IRQF_SHARED,
- 0, _regmap_irq_chip_level2,
- >irq_chip_data_level2);
+   ret = devm_regmap_add_irq_chip(>dev, pmic->regmap, pmic->irq,
+  IRQF_ONESHOT | IRQF_SHARED,
+  0, _regmap_irq_chip_level2,
+  >irq_chip_data_level2);
if (ret) {
dev_err(>dev, "Failed to add secondary IRQ chip\n");
-   goto err_irq_chip_level2;
+   return ret;
}
 
-   ret = regmap_add_irq_chip(pmic->regmap, pmic->irq,
- IRQF_ONESHOT | IRQF_SHARED,
- 0, _regmap_irq_chip_tmu,
- >irq_chip_data_tmu);
+   ret = devm_regmap_add_irq_chip(>dev, pmic->regmap, pmic->irq,
+  IRQF_ONESHOT | IRQF_SHARED,
+  0, _regmap_irq_chip_tmu,
+  >irq_chip_data_tmu);
if (ret) {
dev_err(>dev, "Failed to add TMU IRQ chip\n");
-   goto err_irq_chip_tmu;
+   return ret;
}
 
-   ret = mfd_add_devices(>dev, PLATFORM_DEVID_NONE, bxt_wc_dev,
- ARRAY_SIZE(bxt_wc_dev), NULL, 0,
- NULL);
+   ret = devm_mfd_add_devices(>dev, PLATFORM_DEVID_NONE, bxt_wc_dev,
+  ARRAY_SIZE(bxt_wc_dev), NULL, 0, NULL);
if (ret) {
dev_err(>dev, "Failed to add devices\n");
-   goto err_mfd;
+   return ret;
}
 
ret = sysfs_create_group(>dev.kobj, _group);
if (ret) {
dev_err(>dev, "Failed to create sysfs group %d\n", ret);
-   goto err_sysfs;
+   return ret;
}
 
/*
@@ -451,28 +450,11 @@ static int bxtwc_probe(struct platform_device *pdev)
BXTWC_MIRQLVL1_MCHGR, 0);
 
return 0;
-
-err_sysfs:
-   mfd_remove_devices(>dev);
-err_mfd:
-   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_tmu);
-err_irq_chip_tmu:
-   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_level2);
-err_irq_chip_level2:
-   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
-
-   return ret;
 }
 
 static int bxtwc_remove(struct platform_device *pdev)
 {
-   struct intel_soc_pmic *pmic = dev_get_drvdata(>dev);
-
sysfs_remove_group(>dev.kobj, _group);
-   mfd_remove_devices(>dev);
-   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
-   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_level2);
-   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_tmu);
 
return 0;
 }
-- 
2.7.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 v4 0/9] WCOVE chained IRQ fix

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

Following patch set fixes the chained IRQ issue observed in WCOVE PMIC driver.

Changes since v3:
 * Added fix for typec wcove driver.

Kuppuswamy Sathyanarayanan (9):
  mfd: intel_soc_pmic_bxtwc: fix TMU interrupt index
  mfd: intel_soc_pmic_bxtwc: remove thermal second level irqs
  thermal: intel_bxt_pmic_thermal: use first level PMIC thermal irq
  mfd: intel_soc_pmic_bxtwc: remove second level irq for gpio device
  gpio: gpio-wcove: use first level PMIC GPIO irq
  mfd: intel_soc_pmic_bxtwc: utilize devm_* functions in driver probe
  mfd: intel_soc_pmic_bxtwc: use chained irqs for second level irq chips
  platform: x86: intel_bxtwc_tmu: remove first level irq unmask
  usb: typec: typec_wcove: Use charger irq chip to get usbc virq

 drivers/gpio/gpio-wcove.c|  14 +-
 drivers/mfd/intel_soc_pmic_bxtwc.c   | 234 ---
 drivers/platform/x86/intel_bxtwc_tmu.c   |   4 -
 drivers/thermal/intel_bxt_pmic_thermal.c |   2 +-
 drivers/usb/typec/typec_wcove.c  |   2 +-
 include/linux/mfd/intel_soc_pmic.h   |   5 +-
 6 files changed, 175 insertions(+), 86 deletions(-)

-- 
2.7.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 v4 5/9] gpio: gpio-wcove: use first level PMIC GPIO irq

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

PMIC mfd driver only exports first level irq for GPIO device.
But currently we are reading the irqs from the second level irq
chip, So this patch fixes this issue by adding support to use
first level PMIC GPIO irq.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-by: Linus Walleij 
---
 drivers/gpio/gpio-wcove.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

Changes since v1:
 * used correct mask for GPIO0 and GPIO1 interrupts

Changes since v2: 
 * Rebased on top of latest release.
 * Removed IRQ0 and IRQ1 mask defines.

Changes since v3:
 * None

diff --git a/drivers/gpio/gpio-wcove.c b/drivers/gpio/gpio-wcove.c
index 7b1bc20..bba7704 100644
--- a/drivers/gpio/gpio-wcove.c
+++ b/drivers/gpio/gpio-wcove.c
@@ -401,7 +401,7 @@ static int wcove_gpio_probe(struct platform_device *pdev)
if (!wg)
return -ENOMEM;
 
-   wg->regmap_irq_chip = pmic->irq_chip_data_level2;
+   wg->regmap_irq_chip = pmic->irq_chip_data;
 
platform_set_drvdata(pdev, wg);
 
@@ -449,6 +449,18 @@ static int wcove_gpio_probe(struct platform_device *pdev)
 
gpiochip_set_nested_irqchip(>chip, _irqchip, virq);
 
+   /* Enable GPIO0 interrupts */
+   ret = regmap_update_bits(wg->regmap, IRQ_MASK_BASE, GPIO_IRQ0_MASK,
+0x00);
+   if (ret)
+   return ret;
+
+   /* Enable GPIO1 interrupts */
+   ret = regmap_update_bits(wg->regmap, IRQ_MASK_BASE + 1, GPIO_IRQ1_MASK,
+0x00);
+   if (ret)
+   return ret;
+
return 0;
 }
 
-- 
2.7.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 v4 8/9] platform: x86: intel_bxtwc_tmu: remove first level irq unmask

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

Currently in WCOVE PMIC mfd driver, all second level irq chips
are chained to the respective first level irqs. So there is no
need for explicitly unmasking the first level irq in this
driver. This patches removes this level 1 irq unmask support.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Reviewed-by: Darren Hart (VMware) 
Reviewed-by: Andy Shevchenko 
---
 drivers/platform/x86/intel_bxtwc_tmu.c | 4 
 1 file changed, 4 deletions(-)

Changes since v1:
 * None

Changes since v2:
 * Rebased on top of latest release.

Changes since v3:
 * None

diff --git a/drivers/platform/x86/intel_bxtwc_tmu.c 
b/drivers/platform/x86/intel_bxtwc_tmu.c
index e202abd..ea865d4 100644
--- a/drivers/platform/x86/intel_bxtwc_tmu.c
+++ b/drivers/platform/x86/intel_bxtwc_tmu.c
@@ -92,10 +92,6 @@ static int bxt_wcove_tmu_probe(struct platform_device *pdev)
}
wctmu->irq = virq;
 
-   /* Enable TMU interrupts */
-   regmap_update_bits(wctmu->regmap, BXTWC_MIRQLVL1,
- BXTWC_MIRQLVL1_MTMU, 0);
-
/* Unmask TMU second level Wake & System alarm */
regmap_update_bits(wctmu->regmap, BXTWC_MTMUIRQ_REG,
  BXTWC_TMU_ALRM_MASK, 0);
-- 
2.7.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 v4 3/9] thermal: intel_bxt_pmic_thermal: use first level PMIC thermal irq

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

PMIC mfd driver only exports first level irq for thermal device.
But currently we are reading the irqs from the second level irq
chip, So this patch fixes this issue by adding support to use
first level PMIC thermal irq.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-by: Zhang Rui 
---
 drivers/thermal/intel_bxt_pmic_thermal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Changes since v1:
 * None

Changes since v2: 
 * Rebased on top of latest release.

Changes since v3: 
 * Rebased on top of latest release.

diff --git a/drivers/thermal/intel_bxt_pmic_thermal.c 
b/drivers/thermal/intel_bxt_pmic_thermal.c
index 0f19a39..ef6b322 100644
--- a/drivers/thermal/intel_bxt_pmic_thermal.c
+++ b/drivers/thermal/intel_bxt_pmic_thermal.c
@@ -241,7 +241,7 @@ static int pmic_thermal_probe(struct platform_device *pdev)
}
 
regmap = pmic->regmap;
-   regmap_irq_chip = pmic->irq_chip_data_level2;
+   regmap_irq_chip = pmic->irq_chip_data;
 
pmic_irq_count = 0;
while ((irq = platform_get_irq(pdev, pmic_irq_count)) != -ENXIO) {
-- 
2.7.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 v4 7/9] mfd: intel_soc_pmic_bxtwc: use chained irqs for second level irq chips

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

Whishkey cove PMIC has support to mask/unmask interrupts at two levels.
At first level we can mask/unmask interrupt domains like TMU, GPIO, ADC,
CHGR, BCU THERMAL and PWRBTN and at second level, it provides facility
to mask/unmask individual interrupts belong each of this domain. For
example, in case of TMU, at first level we have TMU interrupt domain,
and at second level we have two interrupts, wake alarm, system alarm that
belong to the TMU interrupt domain.

Currently, in this driver all first level irqs are registered as part of
irq chip(bxtwc_regmap_irq_chip). By default, after you register the irq
chip from your driver, all irqs in that chip will masked and can only be
enabled if that irq is requested using request_irq call. This is the
default Linux irq behavior model. And whenever a dependent device that
belongs to PMIC requests only the second level irq and not explicitly
unmask the first level irq, then in essence the second level irq will
still be disabled. For example, if TMU device driver request wake_alarm
irq and not explicitly unmask TMU level 1 irq then according to the default
Linux irq model,  wake_alarm irq will still be disabled. So the proper
solution to fix this issue is to use the chained irq chip concept. We
should chain all the second level chip irqs to the corresponding first
level irq. To do this, we need to create separate irq chips for every
group of second level irqs.

In case of TMU, when adding second level irq chip, instead of using pmic
irq we should use the corresponding first level irq. So the following
code will change from

ret = regmap_add_irq_chip(pmic->regmap, pmic->irq, ...)

to,

virq = regmap_irq_get_virq(>irq_chip_data, BXTWC_TMU_LVL1_IRQ);

ret = regmap_add_irq_chip(pmic->regmap, virq, ...)

Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-for-MFD-by: Lee Jones 
---
 drivers/mfd/intel_soc_pmic_bxtwc.c | 174 +
 include/linux/mfd/intel_soc_pmic.h |   5 +-
 2 files changed, 144 insertions(+), 35 deletions(-)

Changes since v1:
 * Rebased on top of dev_* cleanup patch.
 * Fixed style & grammer issues reported by Lee Jones

Changes since v2:
 * Rebased on top of latest release.

Changes since v3:
 * None

diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index feeda6e..bd78bef 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -82,18 +82,26 @@ enum bxtwc_irqs {
BXTWC_PWRBTN_IRQ,
 };
 
-enum bxtwc_irqs_level2 {
-   /* Level 2 */
+enum bxtwc_irqs_tmu {
+   BXTWC_TMU_IRQ = 0,
+};
+
+enum bxtwc_irqs_bcu {
BXTWC_BCU_IRQ = 0,
-   BXTWC_ADC_IRQ,
-   BXTWC_USBC_IRQ,
+};
+
+enum bxtwc_irqs_adc {
+   BXTWC_ADC_IRQ = 0,
+};
+
+enum bxtwc_irqs_chgr {
+   BXTWC_USBC_IRQ = 0,
BXTWC_CHGR0_IRQ,
BXTWC_CHGR1_IRQ,
-   BXTWC_CRIT_IRQ,
 };
 
-enum bxtwc_irqs_tmu {
-   BXTWC_TMU_IRQ = 0,
+enum bxtwc_irqs_crit {
+   BXTWC_CRIT_IRQ = 0,
 };
 
 static const struct regmap_irq bxtwc_regmap_irqs[] = {
@@ -108,17 +116,26 @@ static const struct regmap_irq bxtwc_regmap_irqs[] = {
REGMAP_IRQ_REG(BXTWC_PWRBTN_IRQ, 1, 0x03),
 };
 
-static const struct regmap_irq bxtwc_regmap_irqs_level2[] = {
+static const struct regmap_irq bxtwc_regmap_irqs_tmu[] = {
+   REGMAP_IRQ_REG(BXTWC_TMU_IRQ, 0, 0x06),
+};
+
+static const struct regmap_irq bxtwc_regmap_irqs_bcu[] = {
REGMAP_IRQ_REG(BXTWC_BCU_IRQ, 0, 0x1f),
-   REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 1, 0xff),
-   REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 2, BIT(5)),
-   REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 2, 0x1f),
-   REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 3, 0x1f),
-   REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 6, 0x03),
 };
 
-static const struct regmap_irq bxtwc_regmap_irqs_tmu[] = {
-   REGMAP_IRQ_REG(BXTWC_TMU_IRQ, 0, 0x06),
+static const struct regmap_irq bxtwc_regmap_irqs_adc[] = {
+   REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 0, 0xff),
+};
+
+static const struct regmap_irq bxtwc_regmap_irqs_chgr[] = {
+   REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 0, BIT(5)),
+   REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 0, 0x1f),
+   REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 1, 0x1f),
+};
+
+static const struct regmap_irq bxtwc_regmap_irqs_crit[] = {
+   REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 0, 0x03),
 };
 
 static struct regmap_irq_chip bxtwc_regmap_irq_chip = {
@@ -130,15 +147,6 @@ static struct regmap_irq_chip bxtwc_regmap_irq_chip = {
.num_regs = 2,
 };
 
-static struct regmap_irq_chip bxtwc_regmap_irq_chip_level2 = {
-   .name = "bxtwc_irq_chip_level2",
-   .status_base = BXTWC_BCUIRQ,
-   .mask_base = BXTWC_MBCUIRQ,
-   .irqs = bxtwc_regmap_irqs_level2,
-   .num_irqs = ARRAY_SIZE(bxtwc_regmap_irqs_level2),
-   .num_regs = 10,
-};
-
 static struct regmap_irq_chip bxtwc_regmap_irq_chip_tmu = {
.name = "bxtwc_irq_chip_tmu",

[PATCH v4 4/9] mfd: intel_soc_pmic_bxtwc: remove second level irq for gpio device

2017-05-30 Thread sathyanarayanan . kuppuswamy

From: Kuppuswamy Sathyanarayanan 

Currently all PMIC GPIO domain irqs are consumed by the same
device(bxt_wcove_gpio), so there is no need to export them as
separate interrupts. We can just export only the first level
GPIO irq(BXTWC_GPIO_LVL1_IRQ) as an irq resource and let the
GPIO device driver(bxt_wcove_gpio) handle the GPIO sub domain
irqs based on status value of GPIO level2 interrupt status
register. Also, just using only the first level irq will eliminate
the bug involved in requesting only the second level irq and not
explicitly enable the first level irq. For more info on this
issue please read the details at,

https://lkml.org/lkml/2017/2/27/148

Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-for-MFD-by: Lee Jones 
---
 drivers/mfd/intel_soc_pmic_bxtwc.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

Changes since v1:
 * None

Changes since v2: 
 * Rebased on top of latest release.

Changes since v3:
 * None

diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index 7c1ed27..af11c43 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -89,8 +89,6 @@ enum bxtwc_irqs_level2 {
BXTWC_USBC_IRQ,
BXTWC_CHGR0_IRQ,
BXTWC_CHGR1_IRQ,
-   BXTWC_GPIO0_IRQ,
-   BXTWC_GPIO1_IRQ,
BXTWC_CRIT_IRQ,
 };
 
@@ -116,8 +114,6 @@ static const struct regmap_irq bxtwc_regmap_irqs_level2[] = 
{
REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 2, BIT(5)),
REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 2, 0x1f),
REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 3, 0x1f),
-   REGMAP_IRQ_REG(BXTWC_GPIO0_IRQ, 4, 0xff),
-   REGMAP_IRQ_REG(BXTWC_GPIO1_IRQ, 5, 0x3f),
REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 6, 0x03),
 };
 
@@ -153,8 +149,7 @@ static struct regmap_irq_chip bxtwc_regmap_irq_chip_tmu = {
 };
 
 static struct resource gpio_resources[] = {
-   DEFINE_RES_IRQ_NAMED(BXTWC_GPIO0_IRQ, "GPIO0"),
-   DEFINE_RES_IRQ_NAMED(BXTWC_GPIO1_IRQ, "GPIO1"),
+   DEFINE_RES_IRQ_NAMED(BXTWC_GPIO_LVL1_IRQ, "GPIO"),
 };
 
 static struct resource adc_resources[] = {
-- 
2.7.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 v8 2/5] usb: early: add driver for xhci debug capability

2017-05-30 Thread Vlastimil Babka

On 03/21/2017 09:01 AM, Lu Baolu wrote:
> XHCI debug capability (DbC) is an optional but standalone
> functionality provided by an xHCI host controller. Software
> learns this capability by walking through the extended
> capability list of the host. XHCI specification describes
> DbC in the section 7.6.
> 
> This patch introduces the code to probe and initialize the
> debug capability hardware during early boot. With hardware
> initialized, the debug target (system on which this code is
> running) will present a debug device through the debug port
> (normally the first USB3 port). The debug device is fully
> compliant with the USB framework and provides the equivalent
> of a very high performance (USB3) full-duplex serial link
> between the debug host and target. The DbC functionality is
> independent of the xHCI host. There isn't any precondition
> from the xHCI host side for the DbC to work.
> 
> One use for this feature is kernel debugging, for example
> when your machine crashes very early before the regular
> console code is initialized. Other uses include simpler,
> lockless logging instead of a full-blown printk console
> driver and klogd.
> 
> Cc: Ingo Molnar 
> Cc: Mathias Nyman 
> Signed-off-by: Lu Baolu 

...

> +
> +#define XDBC_TRACE
> +#ifdef XDBC_TRACE
> +#define  xdbc_trace  trace_printk

Did you forget to remove the #define XDBC_TRACE?

Enabling this driver brings the "trace_printk() being used. Allocating
extra memory. This means that this is a DEBUG kernel and it is unsafe
for production use." message in 4.12-rcX dmesg.

Thanks,
Vlastimil
--
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/7] driver core: add helper to reuse a device-tree node

2017-05-30 Thread Johan Hovold

Add a helper function to be used when reusing the device-tree node of
another device.

It is fairly common for drivers to reuse the device-tree node of a
parent (or other ancestor) device when creating class or bus devices
(e.g. gpio chips, i2c adapters, iio chips, spi masters, serdev, phys,
usb root hubs). But reusing a device-tree node may cause problems if the
new device is later probed as for example driver core would currently
attempt to reinitialise an already active associated pinmux
configuration.

Other potential issues include the platform-bus code unconditionally
dropping the device-tree node reference in its device destructor,
reinitialisation of other bus-managed resources such as clocks, and the
recently added DMA-setup in driver core.

Note that for most examples above this is currently not an issue as the
devices are never probed, but this is a problem for the USB bus which
has recently gained device-tree support. This was discovered and
worked-around in a rather ad-hoc fashion by commit dc5878abf49c ("usb:
core: move root hub's device node assignment after it is added to bus")
by not setting the of_node pointer until after the root-hub device has
been registered.

Instead we can allow devices to reuse a device-tree node by setting a
flag in their struct device that can be used by core, bus and driver
code to avoid resources from being over-allocated.

Note that the helper also grabs an extra reference to the device node,
which specifically balances the unconditional put in the platform-device
destructor.

Signed-off-by: Johan Hovold 
---
 drivers/base/core.c| 16 
 include/linux/device.h |  2 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index bbecaf9293be..c3064ff09af5 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2884,3 +2884,19 @@ void set_secondary_fwnode(struct device *dev, struct 
fwnode_handle *fwnode)
else
dev->fwnode = fwnode;
 }
+
+/**
+ * device_set_of_node_from_dev - reuse device-tree node of another device
+ * @dev: device whose device-tree node is being set
+ * @dev2: device whose device-tree node is being reused
+ *
+ * Takes another reference to the new device-tree node after first dropping
+ * any reference held to the old node.
+ */
+void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
+{
+   of_node_put(dev->of_node);
+   dev->of_node = of_node_get(dev2->of_node);
+   dev->of_node_reused = true;
+}
+EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518af5515..d7544bb558c3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -966,6 +966,7 @@ struct device {
 
booloffline_disabled:1;
booloffline:1;
+   boolof_node_reused:1;
 };
 
 static inline struct device *kobj_to_dev(struct kobject *kobj)
@@ -1144,6 +1145,7 @@ extern int device_offline(struct device *dev);
 extern int device_online(struct device *dev);
 extern void set_primary_fwnode(struct device *dev, struct fwnode_handle 
*fwnode);
 extern void set_secondary_fwnode(struct device *dev, struct fwnode_handle 
*fwnode);
+void device_set_of_node_from_dev(struct device *dev, const struct device 
*dev2);
 
 static inline int dev_num_vf(struct device *dev)
 {
-- 
2.13.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 5/7] USB: of: fix root-hub device-tree node handling

2017-05-30 Thread Johan Hovold

In an attempt to work around a pinmux over-allocation issue in driver
core, commit dc5878abf49c ("usb: core: move root hub's device node
assignment after it is added to bus") moved the device-tree node
assignment until after the root hub had been registered.

This not only makes the device-tree node unavailable to the usb driver
during probe, but also prevents the of_node from being linked to in
sysfs and causes a race with user-space for the (recently added) devspec
attribute.

Use the new device_set_of_node_from_dev() helper to reuse the node of
the sysdev device, something which now prevents driver core from trying
to reclaim any pinctrl pins during probe.

Fixes: dc5878abf49c ("usb: core: move root hub's device node assignment after 
it is added to bus")
Fixes: 51fa91475e43 ("usb/core: Added devspec sysfs entry for devices behind 
the usb hub")
Signed-off-by: Johan Hovold 
---
 drivers/usb/core/hcd.c | 2 --
 drivers/usb/core/usb.c | 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 5dea98358c05..2cff59e9c268 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1076,7 +1076,6 @@ static void usb_deregister_bus (struct usb_bus *bus)
 static int register_root_hub(struct usb_hcd *hcd)
 {
struct device *parent_dev = hcd->self.controller;
-   struct device *sysdev = hcd->self.sysdev;
struct usb_device *usb_dev = hcd->self.root_hub;
const int devnum = 1;
int retval;
@@ -1123,7 +1122,6 @@ static int register_root_hub(struct usb_hcd *hcd)
/* Did the HC die before the root hub was registered? */
if (HCD_DEAD(hcd))
usb_hc_died (hcd);  /* This time clean up */
-   usb_dev->dev.of_node = sysdev->of_node;
}
mutex_unlock(_bus_idr_lock);
 
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 62e1906bb2f3..17681d5638ac 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -416,8 +416,7 @@ static void usb_release_dev(struct device *dev)
 
usb_destroy_configuration(udev);
usb_release_bos_descriptor(udev);
-   if (udev->parent)
-   of_node_put(dev->of_node);
+   of_node_put(dev->of_node);
usb_put_hcd(hcd);
kfree(udev->product);
kfree(udev->manufacturer);
@@ -616,6 +615,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
dev->route = 0;
 
dev->dev.parent = bus->controller;
+   device_set_of_node_from_dev(>dev, bus->sysdev);
dev_set_name(>dev, "usb%d", bus->busnum);
root_hub = 1;
} else {
-- 
2.13.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 4/7] driver core: fix automatic pinctrl management

2017-05-30 Thread Johan Hovold

Commit ab78029ecc34 ("drivers/pinctrl: grab default handles from device
core") added automatic pin-control management to driver core by looking
up and setting any default pinctrl state found in device tree while a
device is being probed.

This obviously runs into problems as soon as device-tree nodes are
reused for child devices which are later also probed as pins would
already have been claimed by the ancestor device.

For example if a USB host controller claims a pin, its root hub would
consequently fail to probe when its device-tree node is set to the node
of the controller:

pinctrl-single 48002030.pinmux: pin PIN204 already requested by 
48064800.ehci; cannot claim for usb1
pinctrl-single 48002030.pinmux: pin-204 (usb1) status -22
pinctrl-single 48002030.pinmux: could not request pin 204 (PIN204) from 
group usb_dbg_pins  on device pinctrl-single
usb usb1: Error applying setting, reverse things back
usb: probe of usb1 failed with error -22

Fix this by checking the new of_node_reused flag and skipping automatic
pinctrl configuration during probe if set.

Note that the flag is checked in driver core rather than in pinctrl
(e.g. in pinctrl_dt_to_map()) which would specifically have prevented
intentional use of a parent's pinctrl properties by a child device
(should such a need ever arise).

Fixes: ab78029ecc34 ("drivers/pinctrl: grab default handles from device core")
Signed-off-by: Johan Hovold 
---
 drivers/base/pinctrl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 5917b4b5fb99..eb929dd6ef1e 100644
--- a/drivers/base/pinctrl.c
+++ b/drivers/base/pinctrl.c
@@ -23,6 +23,9 @@ int pinctrl_bind_pins(struct device *dev)
 {
int ret;
 
+   if (dev->of_node_reused)
+   return 0;
+
dev->pins = devm_kzalloc(dev, sizeof(*(dev->pins)), GFP_KERNEL);
if (!dev->pins)
return -ENOMEM;
-- 
2.13.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 v4] usb: musb: musb_cppi41: Defer probe only if DMA is not ready

2017-05-30 Thread Bin Liu

On Fri, May 19, 2017 at 04:20:35PM +0200, Alexandre Bailon wrote:
> If dma_request_slave_channel() failed to return a channel,
> then the driver will print an error and request to defer probe,
> regardless of the cause of the failure.
> Defer if the DMA is not ready yet otherwise print an error.
> 
> Signed-off-by: Alexandre Bailon 
> Reviewed-by: Johan Hovold 

Applied. Thanks.
-Bin.

> ---
>  drivers/usb/musb/musb_cppi41.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> index e7c8b1b..ba25528 100644
> --- a/drivers/usb/musb/musb_cppi41.c
> +++ b/drivers/usb/musb/musb_cppi41.c
> @@ -673,12 +673,15 @@ static int cppi41_dma_controller_start(struct 
> cppi41_dma_controller *controller)
>   musb_dma->status = MUSB_DMA_STATUS_FREE;
>   musb_dma->max_len = SZ_4M;
>  
> - dc = dma_request_slave_channel(dev->parent, str);
> - if (!dc) {
> - dev_err(dev, "Failed to request %s.\n", str);
> - ret = -EPROBE_DEFER;
> + dc = dma_request_chan(dev->parent, str);
> + if (IS_ERR(dc)) {
> + ret = PTR_ERR(dc);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to request %s: %d.\n",
> + str, ret);
>   goto err;
>   }
> +
>   cppi41_channel->dc = dc;
>   }
>   return 0;
> -- 
> 2.10.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 0/7] driver core/USB/thermal: fix device-tree node reuse

2017-05-30 Thread Johan Hovold

This series fixes a few issues related to device-tree node reuse.

It is fairly common for drivers to reuse the device-tree node of a
parent (or other ancestor) device when creating class or bus devices
(e.g. gpio chips, i2c adapters, iio chips, spi masters, serdev, phys,
usb root hubs). But reusing a device-tree node may cause problems *if*
the new device is later probed as for example driver core would
currently attempt to reinitialise an already active associated pinmux
configuration.

[ NB: For most examples above this is currently not a problem as the
devices reusing a node are never probed. ]

Other potential issues include the platform-bus code unconditionally
dropping the device-tree-node reference in its device destructor,
reinitialisation of other bus-managed resources such as clocks, and
(possibly) the recently added DMA-setup in driver core.

Instead of having drivers try to work around this (as is currently done
for USB root hubs), we can allow devices to reuse a device-tree node by
setting a flag in their struct device that can be used by core, bus and
driver code to avoid resources from being over-allocated.

The first two patches fix a device-tree node reference leak for
non-root-hub devices in USB. These were submitted yesterday to the USB
list, but are included here for completeness.

The third and fourth patches add a helper that can be used when reusing
a device-tree node of another device and that specifically sets a new
of_node_reused flag which is then used by driver core to skip the
automatic pinctrl configuration during probe.

The fifth patch removes the pinctrl over-allocation workaround from USB
core, which also had some undesirable side-effects.

The final two patches fix a device-tree node imbalance and
use-after-free in an thermal driver, where a platform device was reusing
the device-tree node of its parent mfd during probe. This would also
prevent the child device from being reprobed (e.g. due to probe
deferral) if the parent node defines a pinctrl configuration.

Note that this series is against 4.12-rc3.

For reference, here is a list of relevant commits leading up to the
current situation:

 - [2013-01-22] ab78029ecc34 ("drivers/pinctrl: grab default handles from 
device core")
 - [2016-02-19] 69bec7259853 ("USB: core: let USB device know device node")
 - [2016-04-25] dc5878abf49c ("usb: core: move root hub's device node 
assignment after it is added to bus")
 - [2016-10-06] 51fa91475e43 ("usb/core: Added devspec sysfs entry for devices 
behind the usb hub")
 - [2017-03-13] a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
 - [2017-04-10] 09515ef5ddad ("of/acpi: Configure dma operations at probe time 
for platform/amba/pci bus devices")

Johan


Johan Hovold (7):
  USB: core: fix device node leak
  USB: of: document reference taken by child-lookup helper
  driver core: add helper to reuse a device-tree node
  driver core: fix automatic pinctrl management
  USB: of: fix root-hub device-tree node handling
  thermal: max77620: fix device-node reference imbalance
  thermal: max77620: fix pinmux conflict on reprobe

 drivers/base/core.c| 16 
 drivers/base/pinctrl.c |  3 +++
 drivers/thermal/max77620_thermal.c |  8 ++--
 drivers/usb/core/hcd.c |  2 --
 drivers/usb/core/of.c  |  3 +++
 drivers/usb/core/usb.c |  2 ++
 include/linux/device.h |  2 ++
 7 files changed, 32 insertions(+), 4 deletions(-)

-- 
2.13.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 2/7] USB: of: document reference taken by child-lookup helper

2017-05-30 Thread Johan Hovold

Document that the child-node lookup helper takes a reference to the
device-tree node which needs to be dropped after use.

Signed-off-by: Johan Hovold 
---
 drivers/usb/core/of.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
index d563cbcf76cf..17a4af02cf5b 100644
--- a/drivers/usb/core/of.c
+++ b/drivers/usb/core/of.c
@@ -28,6 +28,9 @@
  *
  * Find the node from device tree according to its port number.
  *
+ * Takes a reference to the returned device-tree node, which needs to be
+ * dropped after use.
+ *
  * Return: On success, a pointer to the device node, %NULL on failure.
  */
 struct device_node *usb_of_get_child_node(struct device_node *parent,
-- 
2.13.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 6/7] thermal: max77620: fix device-node reference imbalance

2017-05-30 Thread Johan Hovold

The thermal child device reuses the parent MFD-device device-tree node
when registering a thermal zone, but did not take a reference to the
node.

This leads to a reference imbalance, and potential use-after-free, when
the node reference is dropped by the platform-bus device destructor
(once for the child and later again for the parent).

Fix this by dropping any reference already held to a device-tree node
and getting a reference to the parent's node which will be balanced on
reprobe or on platform-device release, whichever comes first.

Note that simply clearing the of_node pointer on probe errors and on
driver unbind would not allow the use of device-managed resources as
specifically thermal_zone_of_sensor_unregister() claims that a valid
device-tree node pointer is needed during deregistration (even if it
currently does not seem to use it).

Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting 
junction temp")
Cc: stable  # 4.9
Cc: Laxman Dewangan 
Signed-off-by: Johan Hovold 
---
 drivers/thermal/max77620_thermal.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/max77620_thermal.c 
b/drivers/thermal/max77620_thermal.c
index e9a1fe342760..71d35f3c9215 100644
--- a/drivers/thermal/max77620_thermal.c
+++ b/drivers/thermal/max77620_thermal.c
@@ -104,8 +104,6 @@ static int max77620_thermal_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
-   pdev->dev.of_node = pdev->dev.parent->of_node;
-
mtherm->dev = >dev;
mtherm->rmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!mtherm->rmap) {
@@ -113,6 +111,14 @@ static int max77620_thermal_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
+   /*
+* Drop any current reference to a device-tree node and get a
+* reference to the parent's node which will be balanced on reprobe or
+* on platform-device release.
+*/
+   of_node_put(pdev->dev.of_node);
+   pdev->dev.of_node = of_node_get(pdev->dev.parent->of_node);
+
mtherm->tz_device = devm_thermal_zone_of_sensor_register(>dev, 0,
mtherm, _thermal_ops);
if (IS_ERR(mtherm->tz_device)) {
-- 
2.13.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 7/7] thermal: max77620: fix pinmux conflict on reprobe

2017-05-30 Thread Johan Hovold

Use the new helper for reusing a device-tree node of another device
instead of managing the node references explicitly.

This also makes sure that the new of_node_reuse flag is set if the
device is ever reprobed, something which specifically now avoids driver
core from attempting to claim any pinmux resources already claimed by
the parent device.

Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting 
junction temp")
Cc: Laxman Dewangan 
Signed-off-by: Johan Hovold 
---
 drivers/thermal/max77620_thermal.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/max77620_thermal.c 
b/drivers/thermal/max77620_thermal.c
index 71d35f3c9215..159bbcee8821 100644
--- a/drivers/thermal/max77620_thermal.c
+++ b/drivers/thermal/max77620_thermal.c
@@ -112,12 +112,10 @@ static int max77620_thermal_probe(struct platform_device 
*pdev)
}
 
/*
-* Drop any current reference to a device-tree node and get a
-* reference to the parent's node which will be balanced on reprobe or
-* on platform-device release.
+* The reference taken to the parent's node which will be balanced on
+* reprobe or on platform-device release.
 */
-   of_node_put(pdev->dev.of_node);
-   pdev->dev.of_node = of_node_get(pdev->dev.parent->of_node);
+   device_set_of_node_from_dev(>dev, pdev->dev.parent);
 
mtherm->tz_device = devm_thermal_zone_of_sensor_register(>dev, 0,
mtherm, _thermal_ops);
-- 
2.13.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 v4 0/9] usb: musb: tusb6010_omap: Convert to DMAengine

2017-05-30 Thread Bin Liu

On Thu, May 18, 2017 at 04:11:58PM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v3:
> - typos in commit message of patch 3 and 5 fixed
> - long line fixed in patch 5
> - Ack from Vinod is added to the first patch
> - The series depends on: http://marc.info/?l=linux-omap=149459699415599=2
> 
> Changes since v2:
> - patch 5 from the v1 has been sent separately
>  (usb: musb: tusb6010_omap: Do not reset the other direction's packet size)
> - Added Tested-by from Tony.
> 
> Changes since v1:
> - Fix the port_window support in omap-dma DMAengine driver
> - MUSB_G_NO_SKB_RESERVE quirk flag addition to msub core
> - packet size corruption fix for tusb6010
> - Handle DMA completion for TX also in the DMA callback
> 
> The v1 series was tested with g_cdc where only the DMA was only enabled for TX
> and because of that I have not noticed that the sDMA code was not correct for 
> RX,
> it only worked for TX case.
> 
> The ASYNC mode of tusb6010 is really unstable, we get corrupted TX/RX offset
> register quite easily, but the SYNC mode is stable.
> 
> The series was tested on top of next-20170510 with g_ncm module since with 
> this
> we can use the quirk to avoid skb_reserve and get properly aligned buffers for
> DMA.
> The n810 is using nfsroot.
> 
> The device would not boot to prompt most of the time before patch 5 (packet 
> size
> reset fix).
> With that patch in, the device would boot up fine most of the cases, but will
> fail pretty fast with my stress test [1].
> After the first 9 patch the legacy DMA mode is going to be stable with g_ncm, 
> it
> boots to prompt, and survives the stress test [1].
> 
> The last patch is going the DMAengine conversion and I have run the stress 
> test
> against it over 3 hours (ping-test.sh wrap count is 139).
> 
> [1] Running these in parallel:
> ping -f 192.168.0.2
> ping -f -s 2048 192.168.0.2
> ping-test.sh 192.168.0.2 1
> 
> and (nfsroot) time to time:
> scp root@192.168.0.1:/usr/portage/distfiles/thunderbird-52.1.0.source.tar.xz /
> 
> $ ls -alh /usr/portage/distfiles/thunderbird-52.1.0.source.tar.xz 
> 218M Apr 30 15:46 /usr/portage/distfiles/thunderbird-52.1.0.source.tar.xz
> 
> In essence copy 218M from my host back to the host.
> 
> ping-test.sh (modified version from Tony to show the wrap count):
> #!/bin/bash
> 
> device=$1
> size=$2
> wraps=0
> 
> while [ 1 ]; do
> #echo "Pinging with size $size"
> if ! ping -w0 -c1 -s$size $device > /dev/null 2>&1; then
> break;
> fi
> size=$(expr $size + 1)
> 
> if [ $size -gt 8192 ]; then
>   wraps=$(expr $wraps + 1)
>   echo "wrapping ($wraps) at $size"
> size=1
> fi
> done
> echo "Test ran up to $size"
> 
> Regards,
> Peter
> 
> CC: dmaeng...@vger.kernel.org
> I only send the cover letter and the DMAengine patch for the dmaengine list, 
> the
> rest can be checked - if there is interest - via lkml
> ---
> Peter Ujfalusi (9):
>   dmaengine: omap-dma: port_window support correction for both direction
>   usb: musb: Add quirk to avoid skb reserve in gadget mode
>   usb: musb: tusb6010: Add MUSB_G_NO_SKB_RESERVE to quirks
>   usb: musb: tusb6010_omap: Use one musb_ep_select call in
> tusb_omap_dma_program
>   usb: musb: tusb6010_omap: Create new struct for DMA data/parameters
>   usb: musb: tusb6010_omap: Allocate DMA channels upfront
>   usb: musb: tusb6010: Handle DMA TX completion in DMA callback as well
>   ARM: OMAP2+: DMA: Add slave map entries for 24xx external request
> lines
>   usb: musb: tusb6010_omap: Convert to DMAengine API
> 
>  arch/arm/mach-omap2/dma.c|  24 +++
>  drivers/dma/omap-dma.c   |  39 ++--
>  drivers/usb/musb/musb_core.c |   3 +
>  drivers/usb/musb/musb_core.h |   1 +
>  drivers/usb/musb/tusb6010.c  |  21 +--
>  drivers/usb/musb/tusb6010_omap.c | 379 
> ---
>  6 files changed, 203 insertions(+), 264 deletions(-)
> 

Applied. Thanks.
-Bin.

--
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/7] USB: core: fix device node leak

2017-05-30 Thread Johan Hovold

Make sure to release any OF device-node reference taken when creating
the USB device.

Note that we currently do not hold a reference to the root hub
device-tree node (i.e. the parent controller node).

Fixes: 69bec7259853 ("USB: core: let USB device know device node")
Cc: stable  # v4.6
Cc: Peter Chen 
Signed-off-by: Johan Hovold 
---
 drivers/usb/core/usb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 28b053cacc90..62e1906bb2f3 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -416,6 +416,8 @@ static void usb_release_dev(struct device *dev)
 
usb_destroy_configuration(udev);
usb_release_bos_descriptor(udev);
+   if (udev->parent)
+   of_node_put(dev->of_node);
usb_put_hcd(hcd);
kfree(udev->product);
kfree(udev->manufacturer);
-- 
2.13.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 7/7] thermal: max77620: fix pinmux conflict on reprobe

2017-05-30 Thread Eduardo Valentin

On Tue, May 30, 2017 at 06:25:54PM +0200, Johan Hovold wrote:
> Use the new helper for reusing a device-tree node of another device
> instead of managing the node references explicitly.
> 
> This also makes sure that the new of_node_reuse flag is set if the
> device is ever reprobed, something which specifically now avoids driver
> core from attempting to claim any pinmux resources already claimed by
> the parent device.
> 
> Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting 
> junction temp")
> Cc: Laxman Dewangan 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/thermal/max77620_thermal.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/thermal/max77620_thermal.c 
> b/drivers/thermal/max77620_thermal.c
> index 71d35f3c9215..159bbcee8821 100644
> --- a/drivers/thermal/max77620_thermal.c
> +++ b/drivers/thermal/max77620_thermal.c
> @@ -112,12 +112,10 @@ static int max77620_thermal_probe(struct 
> platform_device *pdev)
>   }
>  
>   /*
> -  * Drop any current reference to a device-tree node and get a
> -  * reference to the parent's node which will be balanced on reprobe or
> -  * on platform-device release.
> +  * The reference taken to the parent's node which will be balanced on
> +  * reprobe or on platform-device release.
>*/
> - of_node_put(pdev->dev.of_node);
> - pdev->dev.of_node = of_node_get(pdev->dev.parent->of_node);
> + device_set_of_node_from_dev(>dev, pdev->dev.parent);

Should this one be squashed with patch 6/7?

>  
>   mtherm->tz_device = devm_thermal_zone_of_sensor_register(>dev, 0,
>   mtherm, _thermal_ops);
> -- 
> 2.13.0
> 
> 

-- 
All the best,
Eduardo Valentin
--
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 v6] usb: typec: Add a sysfs node to manage port type

2017-05-30 Thread Badhri Jagan Sridharan

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
Reviewed-by: Guenter Roeck 
---
Changelog since v1:
- introduced a new variable port_type in struct typec_port to track
  the current port type instead of changing type member in
  typec_capability to address Heikki Krogerus comments.
- changed the output format and strings that would be displayed as
  suggested by Heikki Krogerus.

Changelog since v2:
- introduced a new mutex lock to protect port_type for addressing
  the race conditions identified by Guenter Roeck
- added typec_port_types_drp for printing port_type when cap->type
  is TYPE_PORT_DRP as suggested by Guenter Roeck
- Power role swap and data role swaps would be rejected unless
  port port_type == TYPE_PORT_DRP
- port_type_store would return immediately if the current port_type
  is same as the new port_type as suggested by Guenter Roeck

Changelog since v3:
- Moved as much as code outside port_type_lock as suggested by
  Guenter Roeck
- Removed Change-Id line from commit message identified by
  Greg Kroah-Hartman

Changelog since v4:
- Corrected return value and moved moved one more line of code
  outside port_type_lock in the port_type_store function as
  suggested by Guenter Roeck

Changelog since v6:
- Added back the ABI Documentation which was dropped accidentally
  during patch revisions.

 Documentation/ABI/testing/sysfs-class-typec |  15 
 drivers/usb/typec/typec.c   | 106 +---
 include/linux/usb/typec.h   |   4 ++
 3 files changed, 115 insertions(+), 10 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
index d4a3d23eb09c..5be552e255e9 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -30,6 +30,21 @@ Description:
 
Valid values: source, sink
 
+What:   /sys/class/typec//port_type
+Date:   May 2017
+Contact:   Badhri Jagan Sridharan 
+Description:
+   Indicates the type of the port. This attribute can be used for
+   requesting a change in the port type. Port type change is
+   supported as a synchronous operation, so write(2) to the
+   attribute will not return until the operation has finished.
+
+   Valid values:
+   - source (The port will behave as source only DFP port)
+   - sink (The port will behave as sink only UFP port)
+   - dual (The port will behave as dual-role-data and
+   dual-role-power port)
+
 What:  /sys/class/typec//vconn_source
 Date:  April 2017
 Contact:   Heikki Krogerus 
diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..63644785ce31 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -69,6 +70,8 @@ struct typec_port {
enum typec_role pwr_role;
enum typec_role vconn_role;
enum typec_pwr_opmode   pwr_opmode;
+   enum typec_port_typeport_type;
+   struct mutexport_type_lock;
 
const struct typec_capability   *cap;
 };
@@ -789,6 +792,18 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
 };
 
+static const char * const typec_port_types[] = {
+   [TYPEC_PORT_DFP] = "source",
+   [TYPEC_PORT_UFP] = "sink",
+   [TYPEC_PORT_DRP] = "dual",
+};
+
+static const char * const typec_port_types_drp[] = {
+   [TYPEC_PORT_DFP] = "dual [source] sink",
+   [TYPEC_PORT_UFP] = "dual source [sink]",
+   [TYPEC_PORT_DRP] = "[dual] source sink",
+};
+
 static ssize_t
 preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -846,11 +861,6 @@ static ssize_t data_role_store(struct device *dev,
struct typec_port *port = to_typec_port(dev);
int ret;
 
-   if (port->cap->type != TYPEC_PORT_DRP) {
-   dev_dbg(dev, "data role swap only supported with DRP ports\n");
-   return -EOPNOTSUPP;
-   }
-
if (!port->cap->dr_set) {
dev_dbg(dev, "data role swapping not supported\n");
return -EOPNOTSUPP;
@@ -860,11 +870,22 @@ static ssize_t data_role_store(struct device *dev,
if (ret < 0)
return ret;
 
+   mutex_lock(>port_type_lock);
+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at

Re: [PATCH v5] usb: typec: Add a sysfs node to manage port type

2017-05-30 Thread Badhri Jagan Sridharan

Noticed that I accidentally dropped the ABI documentation for the new
port_type node during patchset revision.
Adding that back and resubmitting the patch.

Thanks,
Badhri.

On Mon, May 29, 2017 at 1:07 PM, Badhri Jagan Sridharan
 wrote:
> Thanks for all the reviews Guenter & Heikki.
> Heikki, Is there anything else that I need to address in this patch ?
> Or is the patch ready to be merged ?
>
> Thanks,
> Badhri
>
> On Mon, May 29, 2017 at 12:56 PM, Badhri Jagan Sridharan
>  wrote:
>> User space applications in some cases have the need to enforce a
>> specific port type(DFP/UFP/DRP). This change allows userspace to
>> attempt setting the desired port type. Low level drivers can
>> however reject the request if the specific port type is not supported.
>>
>> Signed-off-by: Badhri Jagan Sridharan 
>> Reviewed-by: Guenter Roeck 
>> ---
>> Changelog since v1:
>> - introduced a new variable port_type in struct typec_port to track
>>   the current port type instead of changing type member in
>>   typec_capability to address Heikki Krogerus comments.
>> - changed the output format and strings that would be displayed as
>>   suggested by Heikki Krogerus.
>>
>> Changelog since v2:
>> - introduced a new mutex lock to protect port_type for addressing
>>   the race conditions identified by Guenter Roeck
>> - added typec_port_types_drp for printing port_type when cap->type
>>   is TYPE_PORT_DRP as suggested by Guenter Roeck
>> - Power role swap and data role swaps would be rejected unless
>>   port port_type == TYPE_PORT_DRP
>> - port_type_store would return immediately if the current port_type
>>   is same as the new port_type as suggested by Guenter Roeck
>>
>> Changelog since v3:
>> - Moved as much as code outside port_type_lock as suggested by
>>   Guenter Roeck
>> - Removed Change-Id line from commit message identified by
>>   Greg Kroah-Hartman
>>
>> Changelog since v4:
>> - Corrected return value and moved moved one more line of code
>>   outside port_type_lock in the port_type_store function as
>>   suggested by Guenter Roeck
>>
>>  drivers/usb/typec/typec.c | 106 
>> +-
>>  include/linux/usb/typec.h |   4 ++
>>  2 files changed, 100 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
>> index 89e540bb7ff3..63644785ce31 100644
>> --- a/drivers/usb/typec/typec.c
>> +++ b/drivers/usb/typec/typec.c
>> @@ -11,6 +11,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -69,6 +70,8 @@ struct typec_port {
>> enum typec_role pwr_role;
>> enum typec_role vconn_role;
>> enum typec_pwr_opmode   pwr_opmode;
>> +   enum typec_port_typeport_type;
>> +   struct mutexport_type_lock;
>>
>> const struct typec_capability   *cap;
>>  };
>> @@ -789,6 +792,18 @@ static const char * const typec_data_roles[] = {
>> [TYPEC_HOST]= "host",
>>  };
>>
>> +static const char * const typec_port_types[] = {
>> +   [TYPEC_PORT_DFP] = "source",
>> +   [TYPEC_PORT_UFP] = "sink",
>> +   [TYPEC_PORT_DRP] = "dual",
>> +};
>> +
>> +static const char * const typec_port_types_drp[] = {
>> +   [TYPEC_PORT_DFP] = "dual [source] sink",
>> +   [TYPEC_PORT_UFP] = "dual source [sink]",
>> +   [TYPEC_PORT_DRP] = "[dual] source sink",
>> +};
>> +
>>  static ssize_t
>>  preferred_role_store(struct device *dev, struct device_attribute *attr,
>>  const char *buf, size_t size)
>> @@ -846,11 +861,6 @@ static ssize_t data_role_store(struct device *dev,
>> struct typec_port *port = to_typec_port(dev);
>> int ret;
>>
>> -   if (port->cap->type != TYPEC_PORT_DRP) {
>> -   dev_dbg(dev, "data role swap only supported with DRP 
>> ports\n");
>> -   return -EOPNOTSUPP;
>> -   }
>> -
>> if (!port->cap->dr_set) {
>> dev_dbg(dev, "data role swapping not supported\n");
>> return -EOPNOTSUPP;
>> @@ -860,11 +870,22 @@ static ssize_t data_role_store(struct device *dev,
>> if (ret < 0)
>> return ret;
>>
>> +   mutex_lock(>port_type_lock);
>> +   if (port->port_type != TYPEC_PORT_DRP) {
>> +   dev_dbg(dev, "port type fixed at \"%s\"",
>> +typec_port_types[port->port_type]);
>> +   ret = -EOPNOTSUPP;
>> +   goto unlock_and_ret;
>> +   }
>> +
>> ret = port->cap->dr_set(port->cap, ret);
>> if (ret)
>> -   return ret;
>> +   goto unlock_and_ret;
>>
>> -   return size;
>> +   ret = size;
>> +unlock_and_ret:
>> +   mutex_unlock(>port_type_lock);
>> +   return ret;
>>  }
>>
>>  static ssize_t data_role_show(struct device *dev,
>> @@ -885,7 +906,7 @@ static ssize_t

Re: [PATCH 2/7] USB: of: document reference taken by child-lookup helper

2017-05-30 Thread Tyrel Datwyler

On 05/30/2017 09:25 AM, Johan Hovold wrote:
> Document that the child-node lookup helper takes a reference to the
> device-tree node which needs to be dropped after use.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/core/of.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
> index d563cbcf76cf..17a4af02cf5b 100644
> --- a/drivers/usb/core/of.c
> +++ b/drivers/usb/core/of.c
> @@ -28,6 +28,9 @@
>   *
>   * Find the node from device tree according to its port number.
>   *
> + * Takes a reference to the returned device-tree node, which needs to be
> + * dropped after use.
> + *
>   * Return: On success, a pointer to the device node, %NULL on failure.

I would use the same blurb used throughout drivers/of/* for consistency.

 *  Returns a node pointer with refcount incremented, use
 *  of_node_put() on it when done.
 */

Just my 2-cents

-Tyrel

>   */
>  struct device_node *usb_of_get_child_node(struct device_node *parent,
> 

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

39 matches

Mail list logo