[PATCH 0/2] misc: fastrpc: minor fixes.

Here are two minor fixes, one to fix build error on x86 platforms which do not have CONFIG_DMA_SHARED_BUFFER selected, and other is to hanle possiblity of running out of compute context banks. Thanks, srini Srinivas Kandagatla (1): misc: fastrpc: select CONFIG_DMA_SHARED_BUFFER Thierry Escande

[PATCH 1/2] misc: fastrpc: select CONFIG_DMA_SHARED_BUFFER

Fastrpc is a dma buf exporter as well, so select the corresponding DMA_SHARED_BUFFER config to fix below compilation errors on platforms without this config. ld: drivers/misc/fastrpc.o: in function 'fastrpc_free_map': fastrpc.c:(.text+0xbe): undefined reference to 'dma_buf_unmap_attachment' ld: fa

[PATCH] nvmem: core: don't check the return value of notifier chain call

From: Bartosz Golaszewski blocking_notifier_call_chain() returns the value returned by the last registered callback. A positive return value doesn't indicate an error and an nvmem device should correctly register irrespective of any notifier callback failures. Drop the retval check. Fixes: bee11

Re: [PATCH] nvmem: core: fix the return value check when calling the notifier chain

pt., 15 lut 2019 o 11:26 Srinivas Kandagatla napisał(a): > > > > On 15/02/2019 09:41, Bartosz Golaszewski wrote: > >> rval will be masked with STOP MASK, so the above statement could be > >> false even if we have error. > >> So you should consider returning an errono which can be understood by use

Re: [PATCH] nvmem: core: don't check the return value of notifier chain call

On 15/02/2019 10:42, Bartosz Golaszewski wrote: From: Bartosz Golaszewski blocking_notifier_call_chain() returns the value returned by the last registered callback. A positive return value doesn't indicate an error and an nvmem device should correctly register irrespective of any notifier ca

Upon your reply, I will direct you on what to do. I am in the position to guide you. Waiting for your reply.

Dear Friend, It is my Pleasure to write this Letter to you in order to request your partnership for the realization of this money to be transfer to you. If you accept my proposal. Considering the fact, I did not know you in person or even have seen you before but due to the true revelation that I

Re: [PATCH v2] staging: android: ion: Allocate from heap ID directly without mask

Hi John, On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote: > [snip] > Some thoughts, as this ABI break has the potential to be pretty painful. > > 1) Unfortunately, this ABI is exposed *through* libion via > ion_alloc/ion_alloc_fd out to gralloc implementations. Which means it > will

Re: [PATCH] net: hns: Fix object reference leaks in hns_dsaf_roce_reset()

On 14/02/2019 06:41, Huang Zijiang wrote: The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. of_find_device_by_node() is not called for every path, so is this change proper: /* find the platform device corresponding to

[PATCH] regulator: core: Take lock before applying system load

Take the regulator lock before applying system load. Fixes the following lockdep splat: [5.583581] WARNING: CPU: 1 PID: 16 at drivers/regulator/core.c:925 drms_uA_update+0x114/0x360 [5.588467] Modules linked in: [5.596833] CPU: 1 PID: 16 Comm: kworker/1:0 Not tainted 5.0.0-rc6-next-

Re: [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest

On Thu, Feb 14, 2019 at 6:05 PM Frank Rowand wrote: > > On 2/14/19 4:56 PM, Brendan Higgins wrote: > > On Thu, Feb 14, 2019 at 3:57 PM Frank Rowand wrote: > >> > >> On 12/5/18 3:54 PM, Brendan Higgins wrote: > >>> On Tue, Dec 4, 2018 at 2:58 AM Frank Rowand > >>> wrote: > > Hi Brendan

[PATCH v2] ARM: pm: fix HYP/SVC mode mismatch when MCPM is used

MCPM does a soft reset of the CPUs and uses common cpu_resume() routine to perform low-level platform initialization. This results in a try to install HYP stubs for the second time for each CPU and results in false HYP/SVC mode mismatch detection. The HYP stubs are already installed at the beginnin

Re: [RFC PATCH v1 02/25] printk-rb: add prb locking functions

On 2019-02-15, Petr Mladek wrote: >>> void prb_lock(struct prb_cpulock *cpu_lock) >>> { >>> unsigned int flags; >>> int cpu; >> >> I added an explicit preempt_disable here: >> >> cpu = get_cpu(); > > It is superfluous. Preemption is not possible when interrupts > are disabled. I

Re: [PATCH] powerpc: use $(origin ARCH) to select KBUILD_DEFCONFIG

On Fri, Feb 15, 2019 at 10:41 AM Masahiro Yamada wrote: > > I often test all Kconfig commands for all architectures. To ease my > workflow, I want 'make defconfig' at least working without any cross > compiler. > > Currently, arch/powerpc/Makefile checks CROSS_COMPILE to decide the > default defco

Re: [PATCH 2/2] driver core: Fix possible supplier PM-usage counter imbalance

Hi Rafael, On 12/02/2019 12:08, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > If a stateless device link to a certain supplier with > DL_FLAG_PM_RUNTIME set in the flags is added and then removed by the > consumer driver's probe callback, the supplier's PM-runtime usage > counter will b

Re: [PATCH] i2c: cadence: try reset when master receive error interrupts

Hi Sxauwsk, On Wed, Jan 30, 2019 at 3:13 PM sxauwsk wrote: > > When the adapter receive error interrupts, such as NACK, arbitration lost, > cdns_i2c_master_xfer return to the caller directly instead of resuming > the adapter which resulted in the adapter being out of control. > > So when driver d

Re: [PATCH v2 0/2] ARC: rework U-boot arguments handling

On Thu, Feb 14, 2019 at 06:07:43PM +0300, Eugeniy Paltsev wrote: > Reworking U-boot args handling and enable uboot support > unconditionally. > > Changes v1->v2: > * Drop magic number check [in this patch series] > * Keep comment about cndline appending > > Changes RFC->v1: > * Don't add new A

[PATCH V15 01/18] btrfs: look at bi_size for repair decisions

From: Christoph Hellwig bio_readpage_error currently uses bi_vcnt to decide if it is worth retrying an I/O. But the vector count is mostly an implementation artifact - it really should figure out if there is more than a single sector worth retrying. Use bi_size for that and shift by PAGE_SHIFT.

[PATCH V15 00/18] block: support multi-page bvec

Hi, This patchset brings multi-page bvec into block layer: 1) what is multi-page bvec? Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages which are physically contiguous instead of one single page used in linux kernel for long time. 2) why is multi-page bvec introduced? K

[PATCH V15 04/18] block: introduce multi-page bvec helpers

This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec support. The introduced helpers treate one bvec as real multi-page segment, which may include more than one pages. The existed helpers of bvec_iter_* are interfaces for supporting current bvec iterator which is thought as singl

[PATCH V15 03/18] block: remove bvec_iter_rewind()

Commit 7759eb23fd980 ("block: remove bio_rewind_iter()") removes bio_rewind_iter(), then no one uses bvec_iter_rewind() any more, so remove it. Reviewed-by: Omar Sandoval Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei --- include/linux/bvec.h | 24 1 file chang

[PATCH V15 02/18] block: don't use bio->bi_vcnt to figure out segment number

It is wrong to use bio->bi_vcnt to figure out how many segments there are in the bio even though CLONED flag isn't set on this bio, because this bio may be splitted or advanced. So always use bio_segments() in blk_recount_segments(), and it shouldn't cause any performance loss now because the phys

[PATCH V15 08/18] block: introduce mp_bvec_last_segment()

BTRFS and guard_bio_eod() need to get the last singlepage segment from one multipage bvec, so introduce this helper to make them happy. Reviewed-by: Omar Sandoval Signed-off-by: Ming Lei --- include/linux/bvec.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/include

[PATCH V15 05/18] block: introduce bio_for_each_bvec() and rq_for_each_bvec()

bio_for_each_bvec() is used for iterating over multi-page bvec for bio split & merge code. rq_for_each_bvec() can be used for drivers which may handle the multi-page bvec directly, so far loop is one perfect use case. Reviewed-by: Christoph Hellwig Reviewed-by: Omar Sandoval Signed-off-by: Ming

[PATCH V15 06/18] block: use bio_for_each_bvec() to compute multi-page bvec count

First it is more efficient to use bio_for_each_bvec() in both blk_bio_segment_split() and __blk_recalc_rq_segments() to compute how many multi-page bvecs there are in the bio. Secondly once bio_for_each_bvec() is used, the bvec may need to be splitted because its length can be very longer than max

[PATCH V15 10/18] btrfs: use mp_bvec_last_segment to get bio's last page

Preparing for supporting multi-page bvec. Reviewed-by: Omar Sandoval Signed-off-by: Ming Lei --- fs/btrfs/extent_io.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index dc8ba3ee515d..986ef49b0269 100644 --- a/fs/btrfs/exten

[PATCH V15 11/18] block: loop: pass multi-page bvec to iov_iter

iov_iter is implemented on bvec itererator helpers, so it is safe to pass multi-page bvec to it, and this way is much more efficient than passing one page in each bvec. Reviewed-by: Christoph Hellwig Reviewed-by: Omar Sandoval Signed-off-by: Ming Lei --- drivers/block/loop.c | 20 ++---

[PATCH V15 07/18] block: use bio_for_each_bvec() to map sg

It is more efficient to use bio_for_each_bvec() to map sg, meantime we have to consider splitting multipage bvec as done in blk_bio_segment_split(). Reviewed-by: Omar Sandoval Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei --- block/blk-merge.c | 70

[PATCH V15 09/18] fs/buffer.c: use bvec iterator to truncate the bio

Once multi-page bvec is enabled, the last bvec may include more than one page, this patch use mp_bvec_last_segment() to truncate the bio. Reviewed-by: Omar Sandoval Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei --- fs/buffer.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)

[PATCH V15 12/18] bcache: avoid to use bio_for_each_segment_all() in bch_bio_alloc_pages()

bch_bio_alloc_pages() is always called on one new bio, so it is safe to access the bvec table directly. Given it is the only kind of this case, open code the bvec table access since bio_for_each_segment_all() will be changed to support for iterating over multipage bvec. Acked-by: Coly Li Reviewed

[PATCH V15 14/18] block: enable multipage bvecs

This patch pulls the trigger for multi-page bvecs. Reviewed-by: Omar Sandoval Signed-off-by: Ming Lei --- block/bio.c | 22 +++--- fs/iomap.c | 4 ++-- fs/xfs/xfs_aops.c | 4 ++-- include/linux/bio.h | 2 +- 4 files changed, 20 insertions(+), 12 deletions(-

[PATCH V15 13/18] block: allow bio_for_each_segment_all() to iterate over multi-page bvec

This patch introduces one extra iterator variable to bio_for_each_segment_all(), then we can allow bio_for_each_segment_all() to iterate over multi-page bvec. Given it is just one mechannical & simple change on all bio_for_each_segment_all() users, this patch does tree-wide change in one single p

[PATCH V15 15/18] block: always define BIO_MAX_PAGES as 256

Now multi-page bvec can cover CONFIG_THP_SWAP, so we don't need to increase BIO_MAX_PAGES for it. CONFIG_THP_SWAP needs to split one THP into normal pages and adds them all to one bio. With multipage-bvec, it just takes one bvec to hold them all. Reviewed-by: Omar Sandoval Reviewed-by: Christoph

[PATCH V15 16/18] block: document usage of bio iterator helpers

Now multi-page bvec is supported, some helpers may return page by page, meantime some may return segment by segment, this patch documents the usage. Reviewed-by: Christoph Hellwig Reviewed-by: Omar Sandoval Signed-off-by: Ming Lei --- Documentation/block/biovecs.txt | 25 ++

[PATCH V15 17/18] block: kill QUEUE_FLAG_NO_SG_MERGE

Since bdced438acd83ad83a6c ("block: setup bi_phys_segments after splitting"), physical segment number is mainly figured out in blk_queue_split() for fast path, and the flag of BIO_SEG_VALID is set there too. Now only blk_recount_segments() and blk_recalc_rq_segments() use this flag. Basically blk

[PATCH V15 18/18] block: kill BLK_MQ_F_SG_MERGE

QUEUE_FLAG_NO_SG_MERGE has been killed, so kill BLK_MQ_F_SG_MERGE too. Reviewed-by: Christoph Hellwig Reviewed-by: Omar Sandoval Signed-off-by: Ming Lei --- block/blk-mq-debugfs.c | 1 - drivers/block/loop.c | 2 +- drivers/block/nbd.c | 2 +- drivers/block/rbd.c

RE: [PATCH] net: hns: Fix object reference leaks in hns_dsaf_roce_reset()

> From: John Garry > Sent: Friday, February 15, 2019 10:52 AM > > On 14/02/2019 06:41, Huang Zijiang wrote: > > The of_find_device_by_node() takes a reference to the underlying device > > structure, we should release that reference. > > of_find_device_by_node() is not called for every path, so is

Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC LEDs

Hi, On 15-02-19 00:03, Pavel Machek wrote: Hi! I suggest that we deal with this special case by adding 3 custom sysfs attributes: 1) "mode" which when read, prints, e.g. : manual [on-when-charging] While this allows _user on console_ to control everything using echo, it is not suitable for

[PATCH] scripts: gdb: redefine MS_RDONLY

Since commit e262e32d6bde0f77fb0c95d977482fc872c51996 "vfs: Suppress MS_* flag defs within the kernel unless explicitly enabled", the generated gdb scripts can't be used anymore. That commit moved the definition of MS_* flags but forgot to update gdb scripts to use the new location. This patch incl

Re: [PATCH] ASoC: samsung: odroid: Ensure proper sample rate on pri/sec PCM

On 2/15/19 08:24, Krzysztof Kozlowski wrote: > Is this the fix for > "aplay: set_params:1403: Unable to install hw params:" > which appeared in today's next (so after your last round of patches get > merged)? > https://krzk.eu/#/builders/1/builds/3093/steps/24/logs/stdio No, but I have just prepa

Re: [PATCH v6 1/4] acpi: arm64: add iort support for PMCG

On Mon, Feb 04, 2019 at 12:13:21PM +, Shameer Kolothum wrote: > From: Neil Leeder > > Add support for the SMMU Performance Monitor Counter Group > information from ACPI. This is in preparation for its use > in the SMMUv3 PMU driver. > > Signed-off-by: Neil Leeder > Signed-off-by: Hanjun Guo

Re: [PATCH] pre-shared passcode: secure pairing for "no keyboard, no display" devices

Hi! > > Currently, "no keyboard, no display" devices can be paired, but > > pairing is not secure against active attacker. > > > > Can we do better? Not for the first pairing; but for the next ones -- > > yes, I believe we can. > > > > BLE device in this case has internal storage, and Linux runnin

Re: [PATCH 2/2] drivers: devfreq: add tracing for scheduling work

Hi Steven, On 2/14/19 8:07 PM, Steven Rostedt wrote: > On Thu, 14 Feb 2019 19:57:56 +0100 > Lukasz Luba wrote: > >> This patch add basic tracing of the devfreq workqueue and delayed work. >> It aims to capture changes of the polling intervals and device state. >> >> Reviewed-by: Chanwoo Choi >>

[PATCH v1 0/1] perf: High-order AUX allocations

Hi Peter, This supersedes [1]. Since there is no reason not to always go with high order allocations, we simply change the AUX allocator to optimistically do that with a fallback to lower orders. And since this is not an opt-in any more, no tool changes. [1] https://marc.info/?l=linux-kernel&m=15

[PATCH v1 1/1] perf: Optimistically use high order allocations for AUX buffers

Currently, the AUX buffer allocator will use high-order allocations for PMUs that don't support hardware scatter-gather chaining to ensure large contiguous blocks of pages, and always use an array of single pages otherwise. There is, however, a tangible performance benefit in using larger chunks o

Re: [PATCH] arm64/neon: Disable -Wincompatible-pointer-types when building with Clang

On Thu, Feb 14, 2019 at 06:39:59PM -0700, Nathan Chancellor wrote: > After commit cc9f8349cb33 ("arm64: crypto: add NEON accelerated XOR > implementation"), Clang builds for arm64 started failing with the > following error message. Reviewed-by: Mark Brown signature.asc Description: PGP signatur

[PATCH v2 0/8] leds: Add AXP20X CHGLED

This series add support for CHGLED pin found on most of X-Powers PMICs. Changes for v2: - use mutex when accessing hardware registers - fixed LED naming style - fixed some typos - fix variable types when showing attributes - remove useless private data - fix binding documentation - add device cons

[PATCH v2 2/8] mfd: axp20x: Add axp20x-led cell

Add axp20x-led cell for AXP20x, AXP221, AXP223, AXP228, AXP803, AXP809 and AXP813. Signed-off-by: Stefan Mavrodiev --- drivers/mfd/axp20x.c | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c index 3c97f2c0fdfe.

[PATCH v2 7/8] ARM: dts: sun7i: Enable AXP209 CHGLED for Olimex boards

Olimex A20-OLinuXino based boards (MICRO, SOM, SOM204, LIME2) commes with populated LED connected to AXP209. By default the LED is controlled by AXP209, so this binding actually doesn't modify any registers. However this can can be used as general purpose LED, if the control mode is overridden. A

[PATCH v2 4/8] arm64: dts: allwinner: axp803: add charge led node

Add dt node for axp20x-led driver controlling CHGLED. Default status is disabled, since it may be not used. Signed-off-by: Stefan Mavrodiev --- arch/arm64/boot/dts/allwinner/axp803.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi b/arch/arm

[PATCH v2 1/8] leds: Add support for AXP20X CHGLED

Most of AXP20x PMIC chips have built-in battery charger with LED indicator. The LED can be controlled ether by the charger or manually by a register. The default is (except for AXP209) manual control, which makes this LED useless, since there is no device driver. The driver rely on AXP20X MFD dri

[PATCH v2 8/8] ARM: dts: sun8i: a33: Enable AXP223 CHGLED for A33-OLinuXino

A33-OLinuXino comes with populated CHGLED LED indicating battery charging status. By default the control is set to manual mode, which doesn't indicate battery status. So it makes sense to set the control to automatic mode 0 ( FULL - charging, OFF - no battery or battery full). Signed-off-by: Stefa

[PATCH v2 5/8] arm64: dts: allwinner: Enable AXP803 CHGLED for Olimex boards

Teres-I and A64-OLinuXino commes with populated LED connected to AXP803. So to be used as battery indication, pass the LED control to the charger itself in mode 0 ( FULL while charging, OFF no battery or completed). Signed-off-by: Stefan Mavrodiev --- arch/arm64/boot/dts/allwinner/sun50i-a64-oli

[PATCH v2 3/8] dt-bindings: leds: Add binding for axp20x-led device driver

This adds the devicetree bindings for charge led indicator found on most of X-Powers AXP20X PMICs. Signed-off-by: Stefan Mavrodiev --- .../devicetree/bindings/leds/leds-axp20x.txt | 74 +++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/le

[PATCH v2 6/8] arm: dts: axpxx: add charge led node

Add dt node for axp20x-led driver controlling CHGLED. Default status is disabled, since it may be not used. Signed-off-by: Stefan Mavrodiev --- arch/arm/boot/dts/axp209.dtsi | 5 + arch/arm/boot/dts/axp22x.dtsi | 5 + arch/arm/boot/dts/axp81x.dtsi | 5 + 3 files changed, 15 insertion

[PATCH] ARM: dts: rockchip: add chosen node on veyron chromebooks

In order to use earlycon, the stdout-path property needs to be set in the chosen node. Signed-off-by: Enric Balletbo i Serra --- arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/bo

Re: [PATCH v6 1/4] acpi: arm64: add iort support for PMCG

On Mon, Feb 04, 2019 at 12:13:21PM +, Shameer Kolothum wrote: > From: Neil Leeder > > Add support for the SMMU Performance Monitor Counter Group > information from ACPI. This is in preparation for its use > in the SMMUv3 PMU driver. Also, in case I do not get a chance to update it, please ru

[PATCH 2/2] regulator: ltc3676: Fix module description

This driver is for LTC3676 rather than LTC1376. Signed-off-by: Axel Lin --- drivers/regulator/ltc3676.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/ltc3676.c b/drivers/regulator/ltc3676.c index 549a1a243870..e6d66e492b85 100644 --- a/drivers/regulator/lt

[PATCH 1/2] regulator: ltc3676: Simplify .readable_reg and .writable_reg callbacks

Use case range for continuous range to make the code shorter. The .readable_reg and .writable_reg implementation are exactly the same, so use a common ltc3676_readable_writeable_reg function instead. Signed-off-by: Axel Lin --- drivers/regulator/ltc3676.c | 63 +++

[PATCH v0 2/2] perf, pt, coresight: Fix address filters for vmas with non-zero offset

Currently, the address range calculation for file-based filters works as long as the vma that maps the matching part of the object file starts from offset zero into the file (vm_pgoff==0). Otherwise, the resulting filter range would be off by vm_pgoff pages. Another related problem is that in case

[PATCH v0 1/2] perf: Copy parent's address filter offsets on clone

When a child event is allocated in the inherit_event() path, the VMA based filter offsets are not copied from the parent, even though the address space mapping of the new task remains the same, which leads to no trace for the new task until exec. Signed-off-by: Alexander Shishkin Fixes: 375637bc5

[PATCH v0 0/2] perf: Address range filtering fixes

Hi Peter, These are bugfixes for the address range filtering. One had been posted before [1], but fell through the cracks. One was discovered and originally patched by Adrian recently. Both can be theoretically backported all the way to v4.7, but that may require manual conflict resolution and the

Re: [PATCH AUTOSEL 4.20 06/77] ASoC: soc-core: defer card probe until all component is added to list

On Thu, Feb 14, 2019 at 09:07:44PM -0500, Sasha Levin wrote: > From: Ajit Pandey > > [ Upstream commit 8780cf1142a59568a3aa77959cbd76b2edb6fd81 ] > > DAI component probe is not called if it is not present > in component list during sound card registration. > Check if component is available in co

Re: [PATCH AUTOSEL 4.20 10/77] ASoC: soc-core: Hold client_mutex around soc_init_dai_link()

On Thu, Feb 14, 2019 at 09:07:48PM -0500, Sasha Levin wrote: > Fixes: 8780cf1142a5 ("ASoC: soc-core: defer card probe until all component is > added to list") > Reported-by: Kuninori Morimoto I just suggested not backporting the above fix for which this is an incremental fix. signature.asc De

Re: [PATCH 2/2] driver core: Fix possible supplier PM-usage counter imbalance

On Fri, Feb 15, 2019 at 12:00 PM Jon Hunter wrote: > > Hi Rafael, > > On 12/02/2019 12:08, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > If a stateless device link to a certain supplier with > > DL_FLAG_PM_RUNTIME set in the flags is added and then removed by the > > consumer drive

Re: [PATCH AUTOSEL 4.20 16/77] ASoC: soc-core: fix init platform memory handling

On Thu, Feb 14, 2019 at 09:07:54PM -0500, Sasha Levin wrote: > From: Curtis Malainey > > [ Upstream commit 09ac6a817bd687e7f5dac00470262efdd72f9319 ] > > snd_soc_init_platform initializes pointers to snd_soc_dai_link which is > statically allocated and it does this by devm_kzalloc. In the event

Re: [PATCH] net: hns: Fix object reference leaks in hns_dsaf_roce_reset()

On 15/02/2019 11:25, Salil Mehta wrote: From: John Garry Sent: Friday, February 15, 2019 10:52 AM On 14/02/2019 06:41, Huang Zijiang wrote: The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. of_find_device_by_node() is not call

[PATCH] ASoC: samsung: odroid: Add missing DAPM routes

With old DTS there will be missing DAPM routes linking BE with CODECs. Add those routes in the card driver so sound works properly on Odroid XU3/4 also without DTS updates enabling the secondary PCM. Signed-off-by: Sylwester Nawrocki --- This patch might require my previous patch "ASoC: samsung:

Re: [PATCH 2/2] driver core: Fix possible supplier PM-usage counter imbalance

On Friday, February 15, 2019 12:00:27 PM CET Jon Hunter wrote: > Hi Rafael, > > On 12/02/2019 12:08, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > If a stateless device link to a certain supplier with > > DL_FLAG_PM_RUNTIME set in the flags is added and then removed by the > > con

Re: [PATCH 2/4] arm64: dts: rockchip: rockpro64 dts remove unused node

On 2/15/2019 2:48 PM, Heiko Stübner wrote: Am Mittwoch, 13. Februar 2019, 18:06:38 CET schrieb Akash Gajjar: lcd panel pinmux and vcc1v8_s3 regulator is redundant and has a no impact, so removing it. Signed-off-by: Akash Gajjar Hi Heiko, vcc1v8_s3 is actually also a emmc supply, so I'd lik

Re: [PATCH v2 2/4] dt-bindings: gnss: add mediatek binding

On Thu 14 Feb 2019 at 09:11, Johan Hovold wrote: > On Wed, Feb 13, 2019 at 04:24:00PM +0100, Loys Ollivier wrote: >> On Mon 11 Feb 2019 at 14:17, Loys Ollivier wrote: >> > On Mon 11 Feb 2019 at 08:33, Johan Hovold wrote: > >> >> Right, but please do look around for other receivers using this

[PATCH 1/2] cpufreq: intel_pstate: Avoid redundant initialization of local vars

From: Rafael J. Wysocki After commit 1a4fe38add8b ("cpufreq: intel_pstate: Remove max/min fractions to limit performance") the initial value of the pstate local variable in intel_pstate_max_within_limits() and the initial value of the max_pstate local variable in intel_pstate_prepare_request() ar

[PATCH 0/2] cpufreq: intel_pstate: Two cleanups

Hi All, These are just two simple cleanups for intel_pstate, without any expected functional changes. Thanks, Rafael

[PATCH 2/2] cpufreq: intel_pstate: Eliminate intel_pstate_get_base_pstate()

From: Rafael J. Wysocki There is only one caller of intel_pstate_get_base_pstate() and it is more straightforward to carry out the computation directly in the caller, so do that and drop intel_pstate_get_base_pstate(). No intentional changes of behavior. Signed-off-by: Rafael J. Wysocki --- d

Re: [PATCH] pre-shared passcode: secure pairing for "no keyboard, no display" devices

Hi, Den fre 15 feb. 2019 kl 12:46 skrev Pavel Machek : > > Hi! > > > > Currently, "no keyboard, no display" devices can be paired, but > > > pairing is not secure against active attacker. > > > > > > Can we do better? Not for the first pairing; but for the next ones -- > > > yes, I believe we can.

[PATCH] qmi_wwan: apply SET_DTR quirk to Sierra WP7607

The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally as already done for other IDs shared between different devices. Signed-off-by: Beniamino Galvani --- drivers/net/usb/qmi_wwan.c | 4 ++-- 1 file changed, 2 inserti

Re: [PATCH v4 4/4] gnss: add driver for mediatek receivers

On Thu 14 Feb 2019 at 10:12, Johan Hovold wrote: > On Thu, Feb 14, 2019 at 11:00:19AM +0100, Corentin Labbe wrote: >> On Wed, Feb 13, 2019 at 04:09:29PM +0100, Loys Ollivier wrote: >> > Add driver for serial-connected Mediatek-based GNSS receivers. >> > >> > These devices typically boot transm

[PATCH v2 1/4] chardev: add additional check for minor range overlap

Current overlap checking cannot correctly handle a case which is baseminor < existing baseminor && baseminor + minorct > existing baseminor + minorct. Signed-off-by: Chengguang Xu --- v1->v2: - Split fix and cleanup patches. - Remove printing minor range in chrdev_show(). fs/char_dev.c | 6

[PATCH v2 4/4] chardev: update comment based on the code

The function comment of __register_chrdev_region() is out of date, so update it based on the code. Signed-off-by: Chengguang Xu --- v1->v2: - Split fix and cleanup patches. - Remove printing minor range in chrdev_show(). fs/char_dev.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(

[PATCH v2 2/4] chardev: add a check for given minor range

register_chrdev_region() carefully checks minor range before calling __register_chrdev_region() but there is another path from alloc_chrdev_region() which does not check the range properly. So add a check for given minor range in __register_chrdev_region(). Signed-off-by: Chengguang Xu --- v1->v2

Hello

-- Helllo dear my name is Edith Brown i am a U.S military woman i will be glad to know you more better and to be your friend i am waiting for your respond as soon as possible thank you.

[PATCH v2 3/4] chardev: code cleanup for __register_chrdev_region()

It's just code cleanup, not functional change. Signed-off-by: Chengguang Xu --- v1->v2: - Split fix and cleanup patches. - Remove printing minor range in chrdev_show(). fs/char_dev.c | 69 +-- 1 file changed, 28 insertions(+), 41 deletions(-) dif

Re: [PATCH AUTOSEL 3.18 15/16] cfg80211: extend range deviation for DMG

On Thu, 2019-02-14 at 21:15 -0500, Sasha Levin wrote: > From: Chaitanya Tata > > [ Upstream commit 93183bdbe73bbdd03e9566c8dc37c9d06b0d0db6 ] > > Recently, DMG frequency bands have been extended till 71GHz, so extend > the range check till 20GHz (45-71GHZ), else some channels will be marked > as

Re: [PATCH] qmi_wwan: apply SET_DTR quirk to Sierra WP7607

Beniamino Galvani writes: > The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR > quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally as > already done for other IDs shared between different devices. > > Signed-off-by: Beniamino Galvani Thanks. Looks like it's time

[PATCH 1/2] arm64: account for GICv3 LPI tables in static memblock reserve table

In the irqchip and EFI code, we have what basically amounts to a quirk to work around a peculiarity in the GICv3 architecture, which permits the system memory address of LPI tables to be programmable only once after a CPU reset. This means kexec kernels must use the same memory as the first kernel,

[PATCH 2/2] efi/arm: Revert "Defer persistent reservations until after paging_init()"

This reverts commit eff896288872d687d9662000ec9ae11b6d61766f, which deferred the processing of persistent memory reservations to a point where the memory may have already been allocated and overwritten, defeating the purpose. Acked-by: Will Deacon Signed-off-by: Ard Biesheuvel --- arch/arm64/ke

[GIT PULL 0/2] EFI fixes for v5.0-rc

The following changes since commit 1f947a7a011fcceb14cb912f5481a53b18f1879a: Merge branch 'akpm' (patches from Andrew) (2019-02-12 17:15:33 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent for you to fetch changes up to

RE: [PATCH v4] arm64: Add workaround for Fujitsu A64FX erratum 010001

Hi guys, > -Original Message- > From: James Morse [mailto:james.mo...@arm.com] > Sent: Friday, February 15, 2019 3:23 AM > To: Mark Rutland; Zhang, Lei > Cc: 'Will Deacon'; 'Catalin Marinas'; 'linux-kernel@vger.kernel.org'; > 'linux-arm-ker...@lists.infradead.org' > Subject: Re: [PATCH v

Re: [RFC][Patch v8 0/7] KVM: Guest Free Page Hinting

On 2/15/19 4:05 AM, Wang, Wei W wrote: > On Thursday, February 14, 2019 5:43 PM, David Hildenbrand wrote: >> Yes indeed, that is the important bit. They must not be put pack to the >> buddy before they have been processed by the hypervisor. But as the pages >> are not in the buddy, no one allocati

Re: [PATCH] ASoC: samsung: odroid: Add missing DAPM routes

On 2/15/19 13:04, Sylwester Nawrocki wrote: > With old DTS there will be missing DAPM routes linking BE with CODECs. > Add those routes in the card driver so sound works properly on Odroid > XU3/4 also without DTS updates enabling the secondary PCM. > > Signed-off-by: Sylwester Nawrocki I forgot

Re: [PATCH v3 0/9] device connection: Add support for device graphs

Hi Greg, On Thu, Feb 14, 2019 at 11:10:44AM +0100, Greg Kroah-Hartman wrote: > On Wed, Feb 13, 2019 at 10:45:48AM +0300, Heikki Krogerus wrote: > > Hi, > > > > This is the third version of my proposal to add device graph parsing > > to the device connection API. There was only one problem reporte

Re: [PATCH V4 5/9] x86/alternative: Split text_poke_bp() into tree steps

On 2/8/19 1:15 AM, Steven Rostedt wrote: > On Mon, 4 Feb 2019 20:58:58 +0100 > Daniel Bristot de Oliveira wrote: > >> >> +static void text_poke_bp_set_handler(void *addr, void *handler, >> + unsigned char int3) >> +{ >> +bp_int3_handler = handler; >> +bp

Re: [PATCH v5] Coccinelle: semantic code search for missing put_device()

> +@search exists@ > +local idexpression id; > +expression x,e,e1; > +position p1,p2; > +type T,T1,T2,T3; > +@@ > + > +id = of_find_device_by_node@p1(x) > +... when != e = id > +if (id == NULL || ...) { ... return ...; } > +... when != put_device(&id->dev) … > +when != if (id) { ... put_device(

Re: [PATCH] staging: r8822be: check kzalloc return or bail

On Fri, Feb 15, 2019 at 10:24:22AM +0100, Nicholas Mc Guire wrote: > The kzalloc() in halmac_parse_psd_data_88xx() can fail and return NULL > so check the psd_set->data after allocation and if allocation failed > return HALMAC_CMD_PROCESS_ERROR. > > Signed-off-by: Nicholas Mc Guire > Fixes: 938a0

Re: [PATCH] EDAC, altera: Add missing of_node_put()

On Thu, Feb 14, 2019 at 10:15:20AM -0600, Thor Thayer wrote: > Yes, I missed the error path. I mistakingly thought of_node_put(np_eccmgr) > would catch the exit of both branches but I declared sysmgr_np instead of > re-using np_eccmgr. I'll clean that up in a separate patch (actually this > code wi

Re: [PATCH v5] Coccinelle: semantic code search for missing put_device()

On Fri, 15 Feb 2019, Markus Elfring wrote: > > +@search exists@ > > +local idexpression id; > > +expression x,e,e1; > > +position p1,p2; > > +type T,T1,T2,T3; > > +@@ > > + > > +id = of_find_device_by_node@p1(x) > > +... when != e = id > > +if (id == NULL || ...) { ... return ...; } > > +... whe

Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC LEDs

Hi! > >Hardware can automatically control the LED according to the charging > >status, or it can be used as normal software-controlled LED. > > > >I believe we should use trigger to select if hardware controls it or > >not (and then add driver-specific files to describe the > >details). Other prop

[PATCH v2 2/2] drivers: devfreq: add tracing for scheduling work

This patch add basic tracing of the devfreq workqueue and delayed work. It aims to capture changes of the polling intervals and device state. Signed-off-by: Lukasz Luba --- drivers/devfreq/devfreq.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/devfreq/devfreq.c b/drivers/devf

Re: [PATCH 4/4] PM / devfreq: Handle monitor start/stop in the devfreq core

Hi Matthias, On 2/14/19 8:07 PM, Matthias Kaehlcke wrote: > Hi Lukasz, > > On Thu, Feb 14, 2019 at 07:01:36PM +0100, Lukasz Luba wrote: >> Hi Matthias, >> >> I have compiled and run your changes on Odroid xu3 and v5.0-rc6. >> There are kernel warnings because of mutex not held in function >> devf

[PATCH v2 0/2] tracing: drivers: devfreq: add basic trace mechanism

Hi all, This is v2 which implements Steven's suggestions. This patch set adds support for tracing in devfreq framework. It is related to the discussion regarding devfreq workqueue mechanism and wake-ups. These two tracing patches have been submitted in larger patch set, which needs more discussio

[PATCH v2 1/2] trace: events: add devfreq trace event file

The patch adds a new file for with trace events for devfreq framework. They are used for performance analysis of the framework. It also contains updates in MAINTAINERS file adding new entry for devfreq maintainers. Signed-off-by: Lukasz Luba --- MAINTAINERS| 1 + include/tra

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