On 30.05.2017 21:32, Nicolas Repentin wrote:
Hi
Sure.
Using archlinux with 4.11.3-1-ARCH.
[ 44.160746] sd 2:0:0:0: Attached scsi generic sg1 type 0
[ 53.676266] sd 2:0:0:0: [sdb] 5860533168 512-byte logical blocks:
(3.00 TB/2.73 TiB)
[ 53.676276] sd 2:0:0:0: [sdb] 4096-byte physical bloc
On Wed, 31 May 2017 11:27:19 +0800
Lu Baolu wrote:
> >> +
> >> +#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 extr
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
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 u
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 ins
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 inser
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
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
Acke
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
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
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: Ku
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(
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 t
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 |
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
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 dr
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 U
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,
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
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/dri
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 controlle
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 t
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 Sridhara
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 whic
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.
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 th
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 pinmu
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: Pe
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 reusin
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 nod
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 ro
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 nod
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.
>
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&m=149459699415599&w
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
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 incorrec
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 prope
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) [PAT
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 bindin
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/ledtri
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
41 matches
Mail list logo
