[PATCH v4 0/9] WCOVE chained IRQ fix

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

[PATCH v4 1/9] mfd: intel_soc_pmic_bxtwc: fix TMU interrupt index

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

[PATCH v4 6/9] mfd: intel_soc_pmic_bxtwc: utilize devm_* functions in driver probe

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

[PATCH v4 9/9] usb: typec: typec_wcove: Use charger irq chip to get usbc virq

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

[PATCH v4 2/9] mfd: intel_soc_pmic_bxtwc: remove thermal second level irqs

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

[PATCH v4 5/9] gpio: gpio-wcove: use first level PMIC GPIO irq

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.

[PATCH v4 3/9] thermal: intel_bxt_pmic_thermal: use first level PMIC thermal irq

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

[PATCH v4 7/9] mfd: intel_soc_pmic_bxtwc: use chained irqs for second level irq chips

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

[PATCH v4 8/9] platform: x86: intel_bxtwc_tmu: remove first level irq unmask

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

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

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

Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability

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

[PATCH] gadget: Fix a sleep-in-atomic bug

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

Re: [PATCH 4/7] driver core: fix automatic pinctrl management

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 >

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

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

Re: [PATCH 1/7] USB: core: fix device node leak

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

Re: [PATCH 3/7] driver core: add helper to reuse a device-tree node

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

Dear Email User,

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

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

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(+) >

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

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

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

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 &

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

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

Re: [PATCH 7/7] thermal: max77620: fix pinmux conflict on reprobe

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

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

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

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

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

[PATCH 7/7] thermal: max77620: fix pinmux conflict on reprobe

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

[PATCH 1/7] USB: core: fix device node leak

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

[PATCH 0/7] driver core/USB/thermal: fix device-tree node reuse

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

[PATCH 5/7] USB: of: fix root-hub device-tree node handling

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

[PATCH 3/7] driver core: add helper to reuse a device-tree node

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

[PATCH 4/7] driver core: fix automatic pinctrl management

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

Re: [PATCH v4] usb: musb: musb_cppi41: Defer probe only if DMA is not ready

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

Re: [PATCH v4 0/9] usb: musb: tusb6010_omap: Convert to DMAengine

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

Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability

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

Re: Kernel / USB bug

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

Re: [RESEND PATCH v5] ARM: dts: da850: Add the CPPI 4.1 DMA to the USB OTG controller

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

[PATCH V4 0/2] usb: introduce "trigger-sources" DT property for usbport trigger

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

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

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

[PATCH V4 2/2] usb: core: read USB ports from DT in the usbport LED trigger driver

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

[PATCH V4 1/2] dt-bindings: leds: document new trigger-sources property

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