[RFC PATCH v2 2/3] pmbus: Add and expose pmbus_get_info()

This allows the caller to hoist themselves out to a containing structure in e.g. the read/write callbacks without exposing struct pmbus_data. Signed-off-by: Andrew Jeffery --- New since v1. drivers/hwmon/pmbus/pmbus.h | 1 + drivers/hwmon/pmbus/pmbus_core.c | 6 ++ 2

[RFC PATCH v2 2/3] pmbus: Add and expose pmbus_get_info()

This allows the caller to hoist themselves out to a containing structure in e.g. the read/write callbacks without exposing struct pmbus_data. Signed-off-by: Andrew Jeffery --- New since v1. drivers/hwmon/pmbus/pmbus.h | 1 + drivers/hwmon/pmbus/pmbus_core.c | 6 ++ 2 files changed, 7

[RFC PATCH v2 3/3] pmbus: Add MAX31785 driver

The driver features fan control and basic dual-tachometer support. The fan control makes use of the new virtual registers exposed by the pmbus core, mixing use of the default implementations with some overrides via the read/write handlers. FAN_COMMAND_1 on the MAX31785 breaks the values into

[RFC PATCH v2 3/3] pmbus: Add MAX31785 driver

The driver features fan control and basic dual-tachometer support. The fan control makes use of the new virtual registers exposed by the pmbus core, mixing use of the default implementations with some overrides via the read/write handlers. FAN_COMMAND_1 on the MAX31785 breaks the values into

[PATCH 0/4] Add various TI-SCI DT nodes on 66AK2G SoCs

Hi Santosh, The following patch series adds various TI-SCI related DTS nodes that probe the corresponding TI-SCI genpd, clock and reset drivers for the 66AK2G platforms. This is the second of two series, and these nodes along with the defconfig patches finally allows adding other peripherals to

[PATCH 0/4] Add various TI-SCI DT nodes on 66AK2G SoCs

Hi Santosh, The following patch series adds various TI-SCI related DTS nodes that probe the corresponding TI-SCI genpd, clock and reset drivers for the 66AK2G platforms. This is the second of two series, and these nodes along with the defconfig patches finally allows adding other peripherals to

[PATCH 2/4] ARM: dts: keystone-k2g: Add ti-sci power domain node

From: Dave Gerlach Add a ti-sci k2g_pds node to act as our generic power domain provider in the system. Signed-off-by: Dave Gerlach Signed-off-by: Tero Kristo Signed-off-by: Suman Anna ---

[PATCH 1/4] ARM: dts: keystone-k2g: Add PMMC node to support TI-SCI protocol

From: Nishanth Menon Texas Instrument's System Control Interface (TI-SCI) Message Protocol is implemented in Keystone 2 generation 66AK2G SoC with the PMMC entity. Add the ti-sci node representing this 66AK2G PMMC module. Signed-off-by: Nishanth Menon [s-a...@ti.com:

[PATCH 1/4] ARM: dts: keystone-k2g: Add PMMC node to support TI-SCI protocol

From: Nishanth Menon Texas Instrument's System Control Interface (TI-SCI) Message Protocol is implemented in Keystone 2 generation 66AK2G SoC with the PMMC entity. Add the ti-sci node representing this 66AK2G PMMC module. Signed-off-by: Nishanth Menon [s-a...@ti.com: add unit address to DT

[PATCH 2/4] ARM: dts: keystone-k2g: Add ti-sci power domain node

From: Dave Gerlach Add a ti-sci k2g_pds node to act as our generic power domain provider in the system. Signed-off-by: Dave Gerlach Signed-off-by: Tero Kristo Signed-off-by: Suman Anna --- arch/arm/boot/dts/keystone-k2g.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 4/4] ARM: dts: keystone-k2g: Add TI SCI reset-controller node

From: "Andrew F. Davis" Add a reset-controller node for managing resets of various remote processor devices on the SoC over the Texas Instrument's System Control Interface (TI SCI) protocol. Signed-off-by: Andrew F. Davis [s-a...@ti.com: rename node name, drop

[PATCH 4/4] ARM: dts: keystone-k2g: Add TI SCI reset-controller node

From: "Andrew F. Davis" Add a reset-controller node for managing resets of various remote processor devices on the SoC over the Texas Instrument's System Control Interface (TI SCI) protocol. Signed-off-by: Andrew F. Davis [s-a...@ti.com: rename node name, drop obsolete header] Signed-off-by:

[PATCH 3/4] ARM: dts: keystone-k2g: Add ti-sci clock provider node

From: Tero Kristo Add a ti-sci node representing the clock provider in the system. Signed-off-by: Tero Kristo Signed-off-by: Suman Anna --- arch/arm/boot/dts/keystone-k2g.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 3/4] ARM: dts: keystone-k2g: Add ti-sci clock provider node

From: Tero Kristo Add a ti-sci node representing the clock provider in the system. Signed-off-by: Tero Kristo Signed-off-by: Suman Anna --- arch/arm/boot/dts/keystone-k2g.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi

[PATCH 3/3] ARM: configs: keystone: Enable reset drivers

Enable the TI SYSCON and TI-SCI reset drivers for Keystone platforms. These drivers will provide the reset functionality for devices like DSPs or PRU-ICSSs. There are no devices that require these to be built-in, so these are enabled as modules. Signed-off-by: Suman Anna ---

[PATCH 3/3] ARM: configs: keystone: Enable reset drivers

Enable the TI SYSCON and TI-SCI reset drivers for Keystone platforms. These drivers will provide the reset functionality for devices like DSPs or PRU-ICSSs. There are no devices that require these to be built-in, so these are enabled as modules. Signed-off-by: Suman Anna ---

[PATCH 1/3] ARM: configs: keystone: Enable Message Manager

From: Nishanth Menon Message Manager is a communication hardware block on 66AK2G[1] SoCs. Enable the same to provide support for communication with 66AK2G Power Management Micro Controller (PMMC) via the TISCI protocol[2]. [1] http://www.ti.com/product/66ak2g02 [2]

[PATCH 1/3] ARM: configs: keystone: Enable Message Manager

From: Nishanth Menon Message Manager is a communication hardware block on 66AK2G[1] SoCs. Enable the same to provide support for communication with 66AK2G Power Management Micro Controller (PMMC) via the TISCI protocol[2]. [1] http://www.ti.com/product/66ak2g02 [2]

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/14 5:15, Jérôme Glisse wrote: > Sorry i made horrible mistake on names in v4, i completly miss- > understood the suggestion. So here i repost with proper naming. > This is the only change since v3. Again sorry about the noise > with v4. > > Changes since v4: > -

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/14 5:15, Jérôme Glisse wrote: > Sorry i made horrible mistake on names in v4, i completly miss- > understood the suggestion. So here i repost with proper naming. > This is the only change since v3. Again sorry about the noise > with v4. > > Changes since v4: > -

[PATCH 0/3] Keystone defconfig updates

Hi Santosh, The following patch series adds the necessary defconfig options to keystone_defconfig to enable the TI-SCI protocol and their respective genpd/clock/reset drivers. This is the first of two series that provides a baseline for adding and/or enabling other peripherals on the 66AK2G

[PATCH 2/3] ARM: configs: keystone: Enable TI-SCI protocol and genpd driver

From: Nishanth Menon Enable the TI-SCI core protocol and the corresponding genpd driver to enable the essential infrastructure for various device drivers on the 66AK2G family of SoCs. The TI-SCI Clock driver is automatically enabled for ARCH_KEYSTONE. Signed-off-by: Nishanth Menon

[PATCH 2/3] ARM: configs: keystone: Enable TI-SCI protocol and genpd driver

From: Nishanth Menon Enable the TI-SCI core protocol and the corresponding genpd driver to enable the essential infrastructure for various device drivers on the 66AK2G family of SoCs. The TI-SCI Clock driver is automatically enabled for ARCH_KEYSTONE. Signed-off-by: Nishanth Menon

[PATCH 0/3] Keystone defconfig updates

Hi Santosh, The following patch series adds the necessary defconfig options to keystone_defconfig to enable the TI-SCI protocol and their respective genpd/clock/reset drivers. This is the first of two series that provides a baseline for adding and/or enabling other peripherals on the 66AK2G

Re: [PATCH] usb: dwc2: gadget: On USB RESET reset device address to zero

On 07/11/2017 03:25 AM, Minas Harutyunyan wrote: > Reseted DEVADDR field in DCFG to zero on USB RESET. > > Device address in DCFG register does not reset to zero, > which required to pass enumeration, after disconnect and > reconnect. > > Signed-off-by: Minas Harutyunyan >

Re: [PATCH] usb: dwc2: gadget: On USB RESET reset device address to zero

On 07/11/2017 03:25 AM, Minas Harutyunyan wrote: > Reseted DEVADDR field in DCFG to zero on USB RESET. > > Device address in DCFG register does not reset to zero, > which required to pass enumeration, after disconnect and > reconnect. > > Signed-off-by: Minas Harutyunyan > --- >

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 2017/7/18 3:48, Arjan van de Ven wrote: > On 7/17/2017 12:23 PM, Peter Zijlstra wrote: >> Of course, this all assumes a Gaussian distribution to begin with, if we >> get bimodal (or worse) distributions we can still get it wrong. To fix >> that, we'd need to do something better than what we

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 2017/7/18 3:48, Arjan van de Ven wrote: > On 7/17/2017 12:23 PM, Peter Zijlstra wrote: >> Of course, this all assumes a Gaussian distribution to begin with, if we >> get bimodal (or worse) distributions we can still get it wrong. To fix >> that, we'd need to do something better than what we

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 2017/7/18 3:23, Peter Zijlstra wrote: > On Fri, Jul 14, 2017 at 09:26:19AM -0700, Andi Kleen wrote: >>> And as said; Daniel has been working on a better predictor -- now he's >>> probably not used it on the network workload you're looking at, so that >>> might be something to consider. >> >>

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 2017/7/18 3:23, Peter Zijlstra wrote: > On Fri, Jul 14, 2017 at 09:26:19AM -0700, Andi Kleen wrote: >>> And as said; Daniel has been working on a better predictor -- now he's >>> probably not used it on the network workload you're looking at, so that >>> might be something to consider. >> >>

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

于 2017年7月18日 GMT+08:00 上午10:58:52, Chen-Yu Tsai 写到: >On Fri, May 19, 2017 at 4:55 PM, Andre Przywara > wrote: >> Hi, >> >> On 19/05/17 09:29, Icenowy Zheng wrote: >>> >>> >>> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara > 写到:

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

于 2017年7月18日 GMT+08:00 上午10:58:52, Chen-Yu Tsai 写到: >On Fri, May 19, 2017 at 4:55 PM, Andre Przywara > wrote: >> Hi, >> >> On 19/05/17 09:29, Icenowy Zheng wrote: >>> >>> >>> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara > 写到: Hi, On 18/05/17 08:16, Icenowy Zheng wrote: >

Re: [PATCH] scsi: sg: fix static checker warning in sg_is_valid_dxfer

Johannes, > dxfer_len is an unsigned int and we always assign a value > 0 to it, > so it doesn't make any sense to check if it is < 0. We can't really > check dxferp as well as we have both NULL and not NULL cases in the > possible call paths. > > So just return true for SG_DXFER_FROM_DEV

Re: [PATCH] scsi: sg: fix static checker warning in sg_is_valid_dxfer

Johannes, > dxfer_len is an unsigned int and we always assign a value > 0 to it, > so it doesn't make any sense to check if it is < 0. We can't really > check dxferp as well as we have both NULL and not NULL cases in the > possible call paths. > > So just return true for SG_DXFER_FROM_DEV

Re: [linux-sunxi] [PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

On Fri, May 19, 2017 at 10:29 AM, Chen-Yu Tsai wrote: > On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng wrote: >> As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it, >> like the old DTSI files for AXP20x/22x, for the common parts of the >> PMIC.

Re: [linux-sunxi] [PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

On Fri, May 19, 2017 at 10:29 AM, Chen-Yu Tsai wrote: > On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng wrote: >> As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it, >> like the old DTSI files for AXP20x/22x, for the common parts of the >> PMIC. >> >> Signed-off-by: Icenowy

Re: [linux-sunxi] [PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

On Fri, May 19, 2017 at 10:28 AM, Chen-Yu Tsai wrote: > On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng wrote: >> The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC. >> >> Add its device node. >> >> Signed-off-by: Icenowy Zheng

Re: [linux-sunxi] [PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

On Fri, May 19, 2017 at 10:28 AM, Chen-Yu Tsai wrote: > On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng wrote: >> The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC. >> >> Add its device node. >> >> Signed-off-by: Icenowy Zheng > > Reviewed-by: Chen-Yu Tsai Applied for 4.14.

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

On Fri, May 19, 2017 at 4:55 PM, Andre Przywara wrote: > Hi, > > On 19/05/17 09:29, Icenowy Zheng wrote: >> >> >> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara 写到: >>> Hi, >>> >>> On 18/05/17 08:16, Icenowy Zheng wrote: Add support of

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

On Fri, May 19, 2017 at 4:55 PM, Andre Przywara wrote: > Hi, > > On 19/05/17 09:29, Icenowy Zheng wrote: >> >> >> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara 写到: >>> Hi, >>> >>> On 18/05/17 08:16, Icenowy Zheng wrote: Add support of AXP803 regulators in the Pine64 device tree, in order

Re: [PATCH v2 1/2] hpsa: limit transfer length to 1MB

Yadan, > The hpsa firmware will bypass the cache for any request larger > than 1MB, so we should cap the request size to avoid any > performance degradation in kernels later than v4.3 Applied to 4.13/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v2 1/2] hpsa: limit transfer length to 1MB

Yadan, > The hpsa firmware will bypass the cache for any request larger > than 1MB, so we should cap the request size to avoid any > performance degradation in kernels later than v4.3 Applied to 4.13/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux Engineering

RE: [PATCH v2 07/22] fpga: intel: pcie: parse feature list and create platform device for features.

> On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao wrote: > > From: Xiao Guangrong > > > > Device Feature List structure creates a link list of feature headers > > within the MMIO space to provide an extensible way of adding features. > > > > The Intel

RE: [PATCH v2 07/22] fpga: intel: pcie: parse feature list and create platform device for features.

> On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao wrote: > > From: Xiao Guangrong > > > > Device Feature List structure creates a link list of feature headers > > within the MMIO space to provide an extensible way of adding features. > > > > The Intel FPGA PCIe driver walks through the feature headers

[PATCH v3 7/7] drm/rockchip: vop: rk3328: fix overlay abnormal

It's a hardware bug, all window's overlay channel reset value is same, hardware overlay would be die. so we must initial difference id for each overlay channel. The Channel register is supported on all vop will full design. Following is the details for this register VOP_WIN0_CTRL2 bit[7:4]

[PATCH v3 7/7] drm/rockchip: vop: rk3328: fix overlay abnormal

It's a hardware bug, all window's overlay channel reset value is same, hardware overlay would be die. so we must initial difference id for each overlay channel. The Channel register is supported on all vop will full design. Following is the details for this register VOP_WIN0_CTRL2 bit[7:4]

[PATCH v3 3/7] drm/rockchip: vop: move line_flag_num to interrupt registers

In the hardware design process, the design of line flags register is associated with the interrupt register, placing the line flags in the interrupt definition is more reasonable, and it would make multi-vop define easilier. Changes in v3: - Explain more in details, introduce why we need this

[PATCH v3 3/7] drm/rockchip: vop: move line_flag_num to interrupt registers

In the hardware design process, the design of line flags register is associated with the interrupt register, placing the line flags in the interrupt definition is more reasonable, and it would make multi-vop define easilier. Changes in v3: - Explain more in details, introduce why we need this

[PATCH v3 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

Since the drm atomic framework, only a small part of the vop register needs sync write, Currently seems only following registers need sync write: cfg_done, standby and interrupt related register. All ctrl registers are using the sync write method that is inefficient, hardcode the write_relaxed

[PATCH v3 5/7] drm/rockchip: vop: add a series of vop support

Vop Full framework now has following vops: IP versionchipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399 big 3.6 rk3399 lit 3.7 rk3228 3.8 rk3328 The above IP version is from H/W define, some of vop support

[PATCH v3 5/7] drm/rockchip: vop: add a series of vop support

Vop Full framework now has following vops: IP versionchipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399 big 3.6 rk3399 lit 3.7 rk3228 3.8 rk3328 The above IP version is from H/W define, some of vop support

[PATCH v3 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

Since the drm atomic framework, only a small part of the vop register needs sync write, Currently seems only following registers need sync write: cfg_done, standby and interrupt related register. All ctrl registers are using the sync write method that is inefficient, hardcode the write_relaxed

[PATCH v3 6/7] dt-bindings: display: fill Documents for series of vop

Changes in v2: - rename rk322x to rk3228(Heiko Stübner) Signed-off-by: Mark Yao --- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v3 6/7] dt-bindings: display: fill Documents for series of vop

Changes in v2: - rename rk322x to rk3228(Heiko Stübner) Signed-off-by: Mark Yao --- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt

[PATCH v3 4/7] drm/rockchip: vop: group vop registers

Grouping the vop registers facilitates make register definition clearer, and also is useful for different vop reuse the same group register. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 99 +-

[PATCH v3 1/7] drm/rockchip: vop: initialize registers directly

At present we are using init_table to initialize some registers, but the Register init table use un-document define, it is unreadable, and sometimes we only want to update tiny bits, init table method is not friendly, it's diffcult to reuse for difference chips. To make it clean, initialize

[PATCH v3 1/7] drm/rockchip: vop: initialize registers directly

At present we are using init_table to initialize some registers, but the Register init table use un-document define, it is unreadable, and sometimes we only want to update tiny bits, init table method is not friendly, it's diffcult to reuse for difference chips. To make it clean, initialize

[PATCH v3 4/7] drm/rockchip: vop: group vop registers

Grouping the vop registers facilitates make register definition clearer, and also is useful for different vop reuse the same group register. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 99 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h |

[PATCH v3 0/7] drm/rockchip: add all full framework vop support

These patches try to make all current rockchip full framework vop works on drm, fill missing vop on full framework. Vop Full framework now has following vops: IP versionchipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399 big

[PATCH v3 0/7] drm/rockchip: add all full framework vop support

These patches try to make all current rockchip full framework vop works on drm, fill missing vop on full framework. Vop Full framework now has following vops: IP versionchipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399 big

Re: [PATCH] pci: quirk: Apply APM ACS quirk to XGene devices

On Mon, 17 Jul 2017 17:45:52 -0700 Feng Kan wrote: > The APM X-Gene PCIe root port does not support ACS at this point. > Since the root does not allow peer to peer transactions, mask out > ACS capability flag bits. > > Signed-off-by: Feng Kan > --- >

Re: [PATCH] pci: quirk: Apply APM ACS quirk to XGene devices

On Mon, 17 Jul 2017 17:45:52 -0700 Feng Kan wrote: > The APM X-Gene PCIe root port does not support ACS at this point. > Since the root does not allow peer to peer transactions, mask out > ACS capability flag bits. > > Signed-off-by: Feng Kan > --- > drivers/pci/quirks.c | 2 ++ > 1 file

Re: [RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred

Hi Oliver, Thanks for your reply. On 07/17/2017 11:26 PM, Oliver Neukum wrote: Am Mittwoch, den 12.07.2017, 10:27 +0800 schrieb jeffy: Hi Oliver, Thanx for your comments, and sorry for reply late. If you do that you have to change submit_tx_urb() to be called under a spinlock. sorry, why

Re: [RFC PATCH] Bluetooth: btusb: Fix memory leak in play_deferred

Hi Oliver, Thanks for your reply. On 07/17/2017 11:26 PM, Oliver Neukum wrote: Am Mittwoch, den 12.07.2017, 10:27 +0800 schrieb jeffy: Hi Oliver, Thanx for your comments, and sorry for reply late. If you do that you have to change submit_tx_urb() to be called under a spinlock. sorry, why

Re: [PATCH v12 6/8] mm: support reporting free page blocks

On 07/17/2017 11:24 PM, Michal Hocko wrote: On Fri 14-07-17 22:17:13, Michael S. Tsirkin wrote: On Fri, Jul 14, 2017 at 02:30:23PM +0200, Michal Hocko wrote: On Wed 12-07-17 20:40:19, Wei Wang wrote: This patch adds support for reporting blocks of pages on the free list specified by the

Re: [PATCH v12 6/8] mm: support reporting free page blocks

On 07/17/2017 11:24 PM, Michal Hocko wrote: On Fri 14-07-17 22:17:13, Michael S. Tsirkin wrote: On Fri, Jul 14, 2017 at 02:30:23PM +0200, Michal Hocko wrote: On Wed 12-07-17 20:40:19, Wei Wang wrote: This patch adds support for reporting blocks of pages on the free list specified by the

[RFC PATCH v2] Bluetooth: btusb: Fix memory leak in play_deferred

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c

[RFC PATCH v2] Bluetooth: btusb: Fix memory leak in play_deferred

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c

[RFC PATCH v2] Bluetooth: btusb: Fix memory leak in play_deferred

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c

[RFC PATCH v2] Bluetooth: btusb: Fix memory leak in play_deferred

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c

Re: [PATCH v2 2/2] staging: gs_fpgaboot: change char to u8

On Mon, Jul 17, 2017 at 06:22:08PM -0700, Joe Perches wrote: > read_bitstream takes an int rdsize, not a u16. > and this function will overflow tbuf if len > 64 > > static void readinfo_bitstream(char *bitdata, char *buf, int *offset) > { > char tbuf[64]; > s32 len; > > /* read

Re: [PATCH v2 2/2] staging: gs_fpgaboot: change char to u8

On Mon, Jul 17, 2017 at 06:22:08PM -0700, Joe Perches wrote: > read_bitstream takes an int rdsize, not a u16. > and this function will overflow tbuf if len > 64 > > static void readinfo_bitstream(char *bitdata, char *buf, int *offset) > { > char tbuf[64]; > s32 len; > > /* read

Re: [RFC PATCH v1 5/6] mm: parallelize clear_gigantic_page

On 07/17/2017 12:02 PM, Dave Hansen wrote: On 07/14/2017 03:16 PM, daniel.m.jor...@oracle.com wrote: Machine: Intel(R) Xeon(R) CPU E7-8895 v3 @ 2.60GHz, 288 cpus, 1T memory Test:Clear a range of gigantic pages nthread speedup size (GiB) min time (s) stdev 1

Re: [RFC PATCH v1 5/6] mm: parallelize clear_gigantic_page

On 07/17/2017 12:02 PM, Dave Hansen wrote: On 07/14/2017 03:16 PM, daniel.m.jor...@oracle.com wrote: Machine: Intel(R) Xeon(R) CPU E7-8895 v3 @ 2.60GHz, 288 cpus, 1T memory Test:Clear a range of gigantic pages nthread speedup size (GiB) min time (s) stdev 1

[PATCH v3] kbuild: trivial cleanups on the comments

Signed-off-by: Cao jin --- Makefile | 6 +++--- scripts/Kbuild.include | 7 +++ scripts/basic/Makefile | 2 +- 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 7b60fb3..2600f03 100644 --- a/Makefile +++

[PATCH v3] kbuild: trivial cleanups on the comments

Signed-off-by: Cao jin --- Makefile | 6 +++--- scripts/Kbuild.include | 7 +++ scripts/basic/Makefile | 2 +- 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 7b60fb3..2600f03 100644 --- a/Makefile +++ b/Makefile @@ -961,7 +961,7 @@

Re: [PATCH 2/6] f2fs: make max inline size changeable

Hi Jaegeuk, On 2017/7/18 7:12, Jaegeuk Kim wrote: > Hi Chao, > > On 07/16, Chao Yu wrote: >> From: Chao Yu >> >> This patch tries to make below macros calculating max inline size, >> inline dentry field size considerring reserving size-changeable >> space: >> -

Re: [PATCH 2/6] f2fs: make max inline size changeable

Hi Jaegeuk, On 2017/7/18 7:12, Jaegeuk Kim wrote: > Hi Chao, > > On 07/16, Chao Yu wrote: >> From: Chao Yu >> >> This patch tries to make below macros calculating max inline size, >> inline dentry field size considerring reserving size-changeable >> space: >> - MAX_INLINE_DATA >> -

Re: [f2fs-dev] [PATCH v2] f2fs: avoid cpu lockup

On 2017/7/18 6:38, Jaegeuk Kim wrote: > On 07/17, Chao Yu wrote: >> On 2017/7/16 9:04, Jaegeuk Kim wrote: >>> Before retrying to flush data or dentry pages, we need to release cpu in >>> order >>> to prevent watchdog. >>> >>> Signed-off-by: Jaegeuk Kim >> >> Reviewed-by: Chao

Re: [f2fs-dev] [PATCH v2] f2fs: avoid cpu lockup

On 2017/7/18 6:38, Jaegeuk Kim wrote: > On 07/17, Chao Yu wrote: >> On 2017/7/16 9:04, Jaegeuk Kim wrote: >>> Before retrying to flush data or dentry pages, we need to release cpu in >>> order >>> to prevent watchdog. >>> >>> Signed-off-by: Jaegeuk Kim >> >> Reviewed-by: Chao Yu >> >>> --- >>>

linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/vc4/vc4_crtc.c between commit: 1ed134e6526b ("drm/vc4: Fix VBLANK handling in crtc->enable() path") from the drm-misc-fixes tree and commit: 0b20a0f8c3cb ("drm: Add old state pointer to CRTC

linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/vc4/vc4_crtc.c between commit: 1ed134e6526b ("drm/vc4: Fix VBLANK handling in crtc->enable() path") from the drm-misc-fixes tree and commit: 0b20a0f8c3cb ("drm: Add old state pointer to CRTC

linux-next: build failure after merge of the drm-misc tree

Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: Caused by commit b6dcaaac4474 ("drm/vblank: _ioctl posfix for ioctl handler") interacting with commit d5288c88c67c ("switch compat_drm_wait_vblank() to drm_ioctl_kernel()") from

linux-next: build failure after merge of the drm-misc tree

Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: Caused by commit b6dcaaac4474 ("drm/vblank: _ioctl posfix for ioctl handler") interacting with commit d5288c88c67c ("switch compat_drm_wait_vblank() to drm_ioctl_kernel()") from

[RFC] ->poll() sparse annotations

[davem Cc'd, due to sparc/sockets problem involved] On Wed, Jul 05, 2017 at 11:38:21PM +0100, Al Viro wrote: > A side note right back at you - POLL... stuff. I'd redone the old > "hunt the buggy ->poll() instances down" series (took about 12 hours > total), got it to the point where all

[RFC] ->poll() sparse annotations

[davem Cc'd, due to sparc/sockets problem involved] On Wed, Jul 05, 2017 at 11:38:21PM +0100, Al Viro wrote: > A side note right back at you - POLL... stuff. I'd redone the old > "hunt the buggy ->poll() instances down" series (took about 12 hours > total), got it to the point where all

Re: [PATCH v5 2/5] tick: Add freeze timer events

On Tue, Jul 18, 2017 at 2:30 AM, dbasehore . wrote: > On Sat, Jul 15, 2017 at 5:39 AM, Rafael J. Wysocki wrote: >> On Thursday, July 13, 2017 03:58:53 PM dbasehore . wrote: >>> On Thu, Jul 13, 2017 at 8:09 AM, Rafael J. Wysocki >>>

Re: [PATCH v5 2/5] tick: Add freeze timer events

On Tue, Jul 18, 2017 at 2:30 AM, dbasehore . wrote: > On Sat, Jul 15, 2017 at 5:39 AM, Rafael J. Wysocki wrote: >> On Thursday, July 13, 2017 03:58:53 PM dbasehore . wrote: >>> On Thu, Jul 13, 2017 at 8:09 AM, Rafael J. Wysocki >>> wrote: >>> > On Thu, Jul 13, 2017 at 9:32 AM, Peter Zijlstra

Re: [PATCH 01/11] clk: mmp: Drop unnecessary static

On 07/15, Julia Lawall wrote: > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @bad exists@ > position p; >

Re: [PATCH 01/11] clk: mmp: Drop unnecessary static

On 07/15, Julia Lawall wrote: > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @bad exists@ > position p; >

Re: [PATCH 02/11] clk: moxart: Drop unnecessary static

On 07/15, Julia Lawall wrote: > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @bad exists@ > position p; >

Re: [PATCH 02/11] clk: moxart: Drop unnecessary static

On 07/15, Julia Lawall wrote: > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @bad exists@ > position p; >

Re: [PATCH v2] clk: moxart: remove unnecessary statics

On 07/04, Gustavo A. R. Silva wrote: > Remove unnecessary static on local variable _base_ in both functions > moxart_of_pll_clk_init() and moxart_of_apb_clk_init(). Such variables > are initialized before being used, on every execution path throughout > the mentioned functions. The statics have no

Re: [PATCH v2] clk: moxart: remove unnecessary statics

On 07/04, Gustavo A. R. Silva wrote: > Remove unnecessary static on local variable _base_ in both functions > moxart_of_pll_clk_init() and moxart_of_apb_clk_init(). Such variables > are initialized before being used, on every execution path throughout > the mentioned functions. The statics have no

Re: [PATCH v7 06/16] lockdep: Detect and handle hist_lock ring buffer overwrite

On Thu, Jul 13, 2017 at 10:14:42AM +0200, Peter Zijlstra wrote: > +static void __crossrelease_end(unsigned int *stamp) > +{ [snip] > + > + /* > + * If we rewind past the tail; all of history is lost. > + */ > + if ((current->xhlock_idx_max - *stamp) < MAX_XHLOCKS_NR) > +

Re: [PATCH v7 06/16] lockdep: Detect and handle hist_lock ring buffer overwrite

On Thu, Jul 13, 2017 at 10:14:42AM +0200, Peter Zijlstra wrote: > +static void __crossrelease_end(unsigned int *stamp) > +{ [snip] > + > + /* > + * If we rewind past the tail; all of history is lost. > + */ > + if ((current->xhlock_idx_max - *stamp) < MAX_XHLOCKS_NR) > +

Re: [f2fs-dev] [PATCH v6 1/1] f2fs: dax: implement direct access

On 2017/7/12 17:06, sunqiuyang wrote: From: Qiuyang Sun This patch implements Direct Access (DAX) in F2FS, including: - a mount option to choose whether to enable DAX or not - read/write and mmap of regular files in the DAX way - zero-out of unaligned partial blocks in

Re: [f2fs-dev] [PATCH v6 1/1] f2fs: dax: implement direct access

On 2017/7/12 17:06, sunqiuyang wrote: From: Qiuyang Sun This patch implements Direct Access (DAX) in F2FS, including: - a mount option to choose whether to enable DAX or not - read/write and mmap of regular files in the DAX way - zero-out of unaligned partial blocks in the DAX way - garbage

Re: [f2fs-dev] [PATCH] f2fs: include seq_file.h for sysfs.c

On 2017/7/18 0:55, Jaegeuk Kim wrote: > On 07/17, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2017/7/14 9:01, Jaegeuk Kim wrote: >>> This patch includes seq_file.h to avoid compile error. >> >> I didn't hit the error, I guess that's because we have included f2fs_fs.h >> in sysfs.c, the inclusion

Re: [f2fs-dev] [PATCH] f2fs: include seq_file.h for sysfs.c

On 2017/7/18 0:55, Jaegeuk Kim wrote: > On 07/17, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2017/7/14 9:01, Jaegeuk Kim wrote: >>> This patch includes seq_file.h to avoid compile error. >> >> I didn't hit the error, I guess that's because we have included f2fs_fs.h >> in sysfs.c, the inclusion

<    1   2   3   4   5   6   7   8   9   10   >