[PATCH V8 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

PHY transceiver driver for QUSB2 phy controller that provides HighSpeed functionality for DWC3 controller present on Qualcomm chipsets. Signed-off-by: Vivek Gautam Reviewed-by: Stephen Boyd --- Changes since v7: - Fixed 'checkpatch --strict'

[PATCH V8 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

Qualcomm SOCs have QMP phy controller that provides support to a number of controller, viz. PCIe, UFS, and USB. Add a new driver, based on generic phy framework, for this phy controller. Signed-off-by: Vivek Gautam Tested-by: Srinivas Kandagatla

[PATCH V8 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

PHY transceiver driver for QUSB2 phy controller that provides HighSpeed functionality for DWC3 controller present on Qualcomm chipsets. Signed-off-by: Vivek Gautam Reviewed-by: Stephen Boyd --- Changes since v7: - Fixed 'checkpatch --strict' alignment warnings/checks. Changes since v6: -

[PATCH V8 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

Qualcomm SOCs have QMP phy controller that provides support to a number of controller, viz. PCIe, UFS, and USB. Add a new driver, based on generic phy framework, for this phy controller. Signed-off-by: Vivek Gautam Tested-by: Srinivas Kandagatla Reviewed-by: Stephen Boyd --- Changes since v7:

[PATCH V8 1/4] dt-bindings: phy: Add support for QUSB2 phy

Qualcomm chipsets have QUSB2 phy controller that provides HighSpeed functionality for DWC3 controller. Adding dt binding information for the same. Signed-off-by: Vivek Gautam Reviewed-by: Stephen Boyd Acked-by: Rob Herring ---

[PATCH V8 1/4] dt-bindings: phy: Add support for QUSB2 phy

Qualcomm chipsets have QUSB2 phy controller that provides HighSpeed functionality for DWC3 controller. Adding dt binding information for the same. Signed-off-by: Vivek Gautam Reviewed-by: Stephen Boyd Acked-by: Rob Herring --- Changes since v7: - None, just added Stephen's Reviewed-by tag.

[PATCH V8 3/4] dt-bindings: phy: Add support for QMP phy

Qualcomm chipsets have QMP phy controller that provides support to a number of controller, viz. PCIe, UFS, and USB. Adding dt binding information for the same. Signed-off-by: Vivek Gautam Reviewed-by: Stephen Boyd Acked-by: Rob Herring

[PATCH V8 3/4] dt-bindings: phy: Add support for QMP phy

Qualcomm chipsets have QMP phy controller that provides support to a number of controller, viz. PCIe, UFS, and USB. Adding dt binding information for the same. Signed-off-by: Vivek Gautam Reviewed-by: Stephen Boyd Acked-by: Rob Herring --- Changes since v7: - None, just added Stephen's

[PATCH V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

Hi Kishon, Here's the series with fixed checkpatch warnings/checks. Please pick it for phy/next. This patch series adds couple of PHY drivers for Qualcomm chipsets. a) qcom-qusb2 phy driver: that provides High Speed USB functionality. b) qcom-qmp phy driver: that is a combo phy providing support

[PATCH V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

Hi Kishon, Here's the series with fixed checkpatch warnings/checks. Please pick it for phy/next. This patch series adds couple of PHY drivers for Qualcomm chipsets. a) qcom-qusb2 phy driver: that provides High Speed USB functionality. b) qcom-qmp phy driver: that is a combo phy providing support

Re: [RFC 3/8] nvmet: Use p2pmem in nvme target

I hadn't done this yet but I think a simple closest device in the tree would solve the issue sufficiently. However, I originally had it so the user has to pick the device and I prefer that approach. But if the user picks the device, then why bother restricting what he picks? Because the user

Re: [RFC 3/8] nvmet: Use p2pmem in nvme target

I hadn't done this yet but I think a simple closest device in the tree would solve the issue sufficiently. However, I originally had it so the user has to pick the device and I prefer that approach. But if the user picks the device, then why bother restricting what he picks? Because the user

Re: [PATCH v2 4/9] arm64: hugetlb: Override huge_pte_clear() to support contiguous hugepages

Hi Punit, [auto build test ERROR on arm64/for-next/core] [also build test ERROR on v4.11-rc5 next-20170405] [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/Punit-Agrawal/Support-swap-entries

Re: [PATCH v2 4/9] arm64: hugetlb: Override huge_pte_clear() to support contiguous hugepages

Hi Punit, [auto build test ERROR on arm64/for-next/core] [also build test ERROR on v4.11-rc5 next-20170405] [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/Punit-Agrawal/Support-swap-entries

RE: [PATCH] block-mq: set both block queue and hardware queue restart bit for restart

> -Original Message- > From: KY Srinivasan > Sent: Wednesday, April 5, 2017 9:21 PM > To: Bart Van Assche ; linux- > ker...@vger.kernel.org; linux-bl...@vger.kernel.org; Long Li > ; ax...@kernel.dk > Cc: Stephen Hemminger

RE: [PATCH] block-mq: set both block queue and hardware queue restart bit for restart

> -Original Message- > From: KY Srinivasan > Sent: Wednesday, April 5, 2017 9:21 PM > To: Bart Van Assche ; linux- > ker...@vger.kernel.org; linux-bl...@vger.kernel.org; Long Li > ; ax...@kernel.dk > Cc: Stephen Hemminger > Subject: RE: [PATCH] block-mq: set both block queue and

linux-next: Tree for Apr 6

Hi all, Changes since 20170405: The input tree gained a conflict against the jc_docs tree. The mfd tree still had its build failure for which I reverted a commit. The tip tree lost its build failure but gained a conflict against the pstore tree. The staging tree gained conflicts against

linux-next: Tree for Apr 6

Hi all, Changes since 20170405: The input tree gained a conflict against the jc_docs tree. The mfd tree still had its build failure for which I reverted a commit. The tip tree lost its build failure but gained a conflict against the pstore tree. The staging tree gained conflicts against

[PATCH -mm -v8 3/3] mm, THP, swap: Enable THP swap optimization only if has compound map

From: Huang Ying If there is no compound map for a THP (Transparent Huge Page), it is possible that the map count of some sub-pages of the THP is 0. So it is better to split the THP before swapping out. In this way, the sub-pages not mapped will be freed, and we can avoid

[PATCH -mm -v8 3/3] mm, THP, swap: Enable THP swap optimization only if has compound map

From: Huang Ying If there is no compound map for a THP (Transparent Huge Page), it is possible that the map count of some sub-pages of the THP is 0. So it is better to split the THP before swapping out. In this way, the sub-pages not mapped will be freed, and we can avoid the unnecessary swap

[PATCH -mm -v8 2/3] mm, THP, swap: Check whether THP can be split firstly

From: Huang Ying In the original THP swapping out implementation, before splitting the THP (Transparent Huage Page), the swap cluster will be allocated and the THP will be added into the swap cache. But it is possible that the THP cannot be split, and we must delete the

[PATCH -mm -v8 1/3] mm, THP, swap: Delay splitting THP during swap out

From: Huang Ying In this patch, splitting huge page is delayed from almost the first step of swapping out to after allocating the swap space for the THP (Transparent Huge Page) and adding the THP into the swap cache. This will batch the corresponding operation, thus improve

[PATCH -mm -v8 2/3] mm, THP, swap: Check whether THP can be split firstly

From: Huang Ying In the original THP swapping out implementation, before splitting the THP (Transparent Huage Page), the swap cluster will be allocated and the THP will be added into the swap cache. But it is possible that the THP cannot be split, and we must delete the THP from the swap cache

[PATCH -mm -v8 1/3] mm, THP, swap: Delay splitting THP during swap out

From: Huang Ying In this patch, splitting huge page is delayed from almost the first step of swapping out to after allocating the swap space for the THP (Transparent Huge Page) and adding the THP into the swap cache. This will batch the corresponding operation, thus improve THP swap out

[PATCH -mm -v8 0/3] THP swap: Delay splitting THP during swapping out

From: Huang Ying This patchset is to optimize the performance of Transparent Huge Page (THP) swap. Hi, Andrew, could you help me to check whether the overall design is reasonable? Hi, Hugh, Shaohua, Minchan and Rik, could you help me to review the swap part of the

[PATCH -mm -v8 0/3] THP swap: Delay splitting THP during swapping out

From: Huang Ying This patchset is to optimize the performance of Transparent Huge Page (THP) swap. Hi, Andrew, could you help me to check whether the overall design is reasonable? Hi, Hugh, Shaohua, Minchan and Rik, could you help me to review the swap part of the patchset? Hi, Andrea could

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

Note that the nvme completion queues are still on the host memory, so this means we have lost the ordering between data and completions as they go to different pcie targets. Hmm, in this simple up/down case with a switch, I think it might actually be OK. Transactions might not complete at

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

Note that the nvme completion queues are still on the host memory, so this means we have lost the ordering between data and completions as they go to different pcie targets. Hmm, in this simple up/down case with a switch, I think it might actually be OK. Transactions might not complete at

Re: [PATCH net-next] macb: Add hardware PTP support.

On Wed, Apr 05, 2017 at 06:43:03AM -0700, David Miller wrote: > This patch does too many things at one time. Each entry in that list > of changes above should be a separate change, all posted together as > a group as a proper patch series. And please start a new thread with the next posting.

Re: [PATCH net-next] macb: Add hardware PTP support.

On Wed, Apr 05, 2017 at 06:43:03AM -0700, David Miller wrote: > This patch does too many things at one time. Each entry in that list > of changes above should be a separate change, all posted together as > a group as a proper patch series. And please start a new thread with the next posting.

Re: [PATCH v6 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions

Hi Bjorn, On Wednesday 05 April 2017 10:22 PM, Bjorn Helgaas wrote: > On Wed, Apr 05, 2017 at 02:22:21PM +0530, Kishon Vijay Abraham I wrote: >> Introduce a new EP core layer in order to support endpoint functions in >> linux kernel. This comprises the EPC library (Endpoint Controller Library) >>

Re: [PATCH v6 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions

Hi Bjorn, On Wednesday 05 April 2017 10:22 PM, Bjorn Helgaas wrote: > On Wed, Apr 05, 2017 at 02:22:21PM +0530, Kishon Vijay Abraham I wrote: >> Introduce a new EP core layer in order to support endpoint functions in >> linux kernel. This comprises the EPC library (Endpoint Controller Library) >>

Re: [STABLE REGRESSION] iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3

On Thu, 2017-04-06 at 04:58 +, Song, Hongyan wrote: > Hi Srinivas, > I have checked the patch dose not meets my requirement for ISH. > With this patch sensor properties still losing after resume from S3. What is your test case? I want to try. Thanks, Srinivas > > BR > Song Hongyan >

Re: [STABLE REGRESSION] iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3

On Thu, 2017-04-06 at 04:58 +, Song, Hongyan wrote: > Hi Srinivas, > I have checked the patch dose not meets my requirement for ISH. > With this patch sensor properties still losing after resume from S3. What is your test case? I want to try. Thanks, Srinivas > > BR > Song Hongyan >

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Wed, Apr 05 2017, Matthew Wilcox wrote: > On Thu, Apr 06, 2017 at 10:02:48AM +1000, NeilBrown wrote: >> If you are concerned about space in 'struct address_space', just prune >> some wastage. > > I'm trying to (via wlists). still buggy though. Cool. (I wonder what a wlist is weighted

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Wed, Apr 05 2017, Matthew Wilcox wrote: > On Thu, Apr 06, 2017 at 10:02:48AM +1000, NeilBrown wrote: >> If you are concerned about space in 'struct address_space', just prune >> some wastage. > > I'm trying to (via wlists). still buggy though. Cool. (I wonder what a wlist is weighted

Re: [HMM 00/16] HMM (Heterogeneous Memory Management) v19

On Thu, Apr 06, 2017 at 11:22:12AM +0800, Figo.zhang wrote: [...] > > Heterogeneous Memory Management (HMM) (description and justification) > > > > Today device driver expose dedicated memory allocation API through their > > device file, often relying on a combination of IOCTL and mmap calls.

Re: [HMM 00/16] HMM (Heterogeneous Memory Management) v19

On Thu, Apr 06, 2017 at 11:22:12AM +0800, Figo.zhang wrote: [...] > > Heterogeneous Memory Management (HMM) (description and justification) > > > > Today device driver expose dedicated memory allocation API through their > > device file, often relying on a combination of IOCTL and mmap calls.

RE: [STABLE REGRESSION] iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3

Hi Srinivas, I have checked the patch dose not meets my requirement for ISH. With this patch sensor properties still losing after resume from S3. BR Song Hongyan -Original Message- From: Srinivas Pandruvada [mailto:srinivas.pandruv...@linux.intel.com] Sent: Wednesday, April 5,

RE: [STABLE REGRESSION] iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3

Hi Srinivas, I have checked the patch dose not meets my requirement for ISH. With this patch sensor properties still losing after resume from S3. BR Song Hongyan -Original Message- From: Srinivas Pandruvada [mailto:srinivas.pandruv...@linux.intel.com] Sent: Wednesday, April 5,

Re: [PATCH v9 3/3] printk: fix double printing with earlycon

On 04/06/2017 12:57 AM, Andy Shevchenko wrote: On Wed, Apr 5, 2017 at 11:20 PM, Aleksey Makarov wrote: If a console was specified by ACPI SPCR table _and_ command line parameters like "console=ttyAMA0" _and_ "earlycon" were specified, then log messages appear

Re: [PATCH v9 3/3] printk: fix double printing with earlycon

On 04/06/2017 12:57 AM, Andy Shevchenko wrote: On Wed, Apr 5, 2017 at 11:20 PM, Aleksey Makarov wrote: If a console was specified by ACPI SPCR table _and_ command line parameters like "console=ttyAMA0" _and_ "earlycon" were specified, then log messages appear twice. The root cause is that

Re: [PATCH v3 1/2] soc: qcom: Add support of scm call for mss rproc to share access of ddr

On Wed 08 Mar 10:03 PST 2017, Avaneesh Kumar Dwivedi wrote: > This patch add scm call support to make hypervisor call to enable access > of fw regions in ddr to mss subsystem on arm-v8 arch soc's. > > Signed-off-by: Avaneesh Kumar Dwivedi > --- >

Re: [PATCH v3 1/2] soc: qcom: Add support of scm call for mss rproc to share access of ddr

On Wed 08 Mar 10:03 PST 2017, Avaneesh Kumar Dwivedi wrote: > This patch add scm call support to make hypervisor call to enable access > of fw regions in ddr to mss subsystem on arm-v8 arch soc's. > > Signed-off-by: Avaneesh Kumar Dwivedi > --- > drivers/firmware/qcom_scm-64.c | 25

Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function

2017년 04월 05일 00:38에 Krzysztof Kozlowski 이(가) 쓴 글: > On Tue, Mar 28, 2017 at 11:38 AM, Krzysztof Kozlowski wrote: >> On Tue, Mar 28, 2017 at 11:26 AM, Inki Dae wrote: >>> Merged. >> >> Hi, >> >> I do not see the tag (with DT patches) merged by you which I

Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function

2017년 04월 05일 00:38에 Krzysztof Kozlowski 이(가) 쓴 글: > On Tue, Mar 28, 2017 at 11:38 AM, Krzysztof Kozlowski wrote: >> On Tue, Mar 28, 2017 at 11:26 AM, Inki Dae wrote: >>> Merged. >> >> Hi, >> >> I do not see the tag (with DT patches) merged by you which I provided >> to you before. These are

Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"

On Sat, Apr 1, 2017 at 1:51 AM, Brian Norris wrote: > This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836. > > This above-mentioned "fix" does not actually do anything to prevent a > race condition. It simply papers over it so that the issue doesn't > appear. >

Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"

On Sat, Apr 1, 2017 at 1:51 AM, Brian Norris wrote: > This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836. > > This above-mentioned "fix" does not actually do anything to prevent a > race condition. It simply papers over it so that the issue doesn't > appear. > > If this is a real

Re: [PATCH 5/5] fpga-region: separate out common code from dt specific code

Hi Alan, first pass ... need to get back to it. On Mon, Mar 13, 2017 at 04:53:33PM -0500, Alan Tull wrote: > FPGA region is a layer above the FPGA manager and FPGA bridge > frameworks. Currently, FPGA region is dependent on device tree. > This commit separates the device tree specific code from

Re: [PATCH 5/5] fpga-region: separate out common code from dt specific code

Hi Alan, first pass ... need to get back to it. On Mon, Mar 13, 2017 at 04:53:33PM -0500, Alan Tull wrote: > FPGA region is a layer above the FPGA manager and FPGA bridge > frameworks. Currently, FPGA region is dependent on device tree. > This commit separates the device tree specific code from

RE: [PATCH] block-mq: set both block queue and hardware queue restart bit for restart

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Wednesday, April 5, 2017 8:46 PM > To: linux-kernel@vger.kernel.org; linux-bl...@vger.kernel.org; Long Li > ; ax...@kernel.dk > Cc: Stephen Hemminger ;

RE: [PATCH] block-mq: set both block queue and hardware queue restart bit for restart

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Wednesday, April 5, 2017 8:46 PM > To: linux-kernel@vger.kernel.org; linux-bl...@vger.kernel.org; Long Li > ; ax...@kernel.dk > Cc: Stephen Hemminger ; KY Srinivasan > > Subject: Re: [PATCH]

Re: [PATCH 3/3] perf tool, arm64, thunderx2: Add implementation defined events for ThunderX2

On Wed, Apr 5, 2017 at 3:35 PM, Mark Rutland wrote: > On Wed, Apr 05, 2017 at 02:42:39PM +0530, Ganapatrao Kulkarni wrote: >> On Tue, Apr 4, 2017 at 5:58 PM, Mark Rutland wrote: >> > On Tue, Apr 04, 2017 at 01:06:43PM +0530, Ganapatrao Kulkarni wrote:

Re: [PATCH 3/3] perf tool, arm64, thunderx2: Add implementation defined events for ThunderX2

On Wed, Apr 5, 2017 at 3:35 PM, Mark Rutland wrote: > On Wed, Apr 05, 2017 at 02:42:39PM +0530, Ganapatrao Kulkarni wrote: >> On Tue, Apr 4, 2017 at 5:58 PM, Mark Rutland wrote: >> > On Tue, Apr 04, 2017 at 01:06:43PM +0530, Ganapatrao Kulkarni wrote: >> >> This is not a full event list, but a

[PATCH] PM / devfreq: Move struct devfreq_governor to devfreq directory

This patch moves the struct devfreq_governor from header file to the devfreq directory because this structure is private data and it have to be only accessed by the devfreq core. Signed-off-by: Chanwoo Choi --- drivers/devfreq/governor.h | 29 +

[PATCH] PM / devfreq: Move struct devfreq_governor to devfreq directory

This patch moves the struct devfreq_governor from header file to the devfreq directory because this structure is private data and it have to be only accessed by the devfreq core. Signed-off-by: Chanwoo Choi --- drivers/devfreq/governor.h | 29 +

Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt

On Wed, Apr 05, 2017 at 10:12:24PM -0400, Steven Rostedt wrote: > On Wed, 5 Apr 2017 10:59:25 -0700 > "Paul E. McKenney" wrote: > > > > > Could you please let me know if tracing happens in NMI handlers? > > > > If so, a bit of additional code will be needed. > > > >

Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt

On Wed, Apr 05, 2017 at 10:12:24PM -0400, Steven Rostedt wrote: > On Wed, 5 Apr 2017 10:59:25 -0700 > "Paul E. McKenney" wrote: > > > > > Could you please let me know if tracing happens in NMI handlers? > > > > If so, a bit of additional code will be needed. > > > > > > > >

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

Hi Shuah, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc5] [cannot apply to next-20170405] [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/Shuah-Khan/arm-dma-fix

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

Hi Shuah, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc5] [cannot apply to next-20170405] [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/Shuah-Khan/arm-dma-fix

Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt

On Wed, Apr 05, 2017 at 09:31:45PM -0400, Steven Rostedt wrote: > On Wed, 5 Apr 2017 13:42:29 -0700 > "Paul E. McKenney" wrote: > > > > OK, do you want me to send you a patch, or should I take your patch > > > into my tree and add this? > > > > Given that I don't

Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt

On Wed, Apr 05, 2017 at 09:31:45PM -0400, Steven Rostedt wrote: > On Wed, 5 Apr 2017 13:42:29 -0700 > "Paul E. McKenney" wrote: > > > > OK, do you want me to send you a patch, or should I take your patch > > > into my tree and add this? > > > > Given that I don't seem to have

Re: [PATCH 4/5] fpga-mgr: separate getting/locking FPGA manager

Hi Alan, minor nits, inline On Mon, Mar 13, 2017 at 04:53:32PM -0500, Alan Tull wrote: > Add fpga_mgr_lock/unlock functions that get a mutex for > exclusive use. > > of_fpga_mgr_get, fpga_mgr_get, and fpga_mgr_put no longer lock > the FPGA manager mutex. > > This makes it more straightforward

Re: [PATCH 4/5] fpga-mgr: separate getting/locking FPGA manager

Hi Alan, minor nits, inline On Mon, Mar 13, 2017 at 04:53:32PM -0500, Alan Tull wrote: > Add fpga_mgr_lock/unlock functions that get a mutex for > exclusive use. > > of_fpga_mgr_get, fpga_mgr_get, and fpga_mgr_put no longer lock > the FPGA manager mutex. > > This makes it more straightforward

linux-next: build warning after merge of the scsi tree

Hi James, After merging the scsi tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/linux/list.h:8:0, from include/linux/module.h:9, from drivers/scsi/sd.c:35: drivers/scsi/sd.c: In function

linux-next: build warning after merge of the scsi tree

Hi James, After merging the scsi tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/linux/list.h:8:0, from include/linux/module.h:9, from drivers/scsi/sd.c:35: drivers/scsi/sd.c: In function

Re: [PATCH] mwifiex: MAC randomization should not be persistent

Brian Norris writes: > nl80211 provides the NL80211_SCAN_FLAG_RANDOM_ADDR for every scan > request that should be randomized; the absence of such a flag means we > should not randomize. However, mwifiex was stashing the latest > randomization request and *always* using

Re: [PATCH] mwifiex: MAC randomization should not be persistent

Brian Norris writes: > nl80211 provides the NL80211_SCAN_FLAG_RANDOM_ADDR for every scan > request that should be randomized; the absence of such a flag means we > should not randomize. However, mwifiex was stashing the latest > randomization request and *always* using it for future scans, even

[PATCH] ARM: domains: Extract common USER domain init

Everything but the USER domain is the same with CONFIG_CPU_SW_DOMAIN_PAN or not. This extracts the differences for a common DACR_INIT macro so it is easier to make future changes (like adding the WR_RARE domain). Signed-off-by: Kees Cook --- arch/arm/include/asm/domain.h

[PATCH] ARM: domains: Extract common USER domain init

Everything but the USER domain is the same with CONFIG_CPU_SW_DOMAIN_PAN or not. This extracts the differences for a common DACR_INIT macro so it is easier to make future changes (like adding the WR_RARE domain). Signed-off-by: Kees Cook --- arch/arm/include/asm/domain.h | 14 +++--- 1

[PATCH] mailmap: update Yakir Yang email address

Set current email address to replace previous employers email addresses. Signed-off-by: Jeffy Chen --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index e775f79..de0fc5b 100644 --- a/.mailmap +++ b/.mailmap @@ -172,6 +172,7 @@

[PATCH] mailmap: update Yakir Yang email address

Set current email address to replace previous employers email addresses. Signed-off-by: Jeffy Chen --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index e775f79..de0fc5b 100644 --- a/.mailmap +++ b/.mailmap @@ -172,6 +172,7 @@ Vlad Dogaru Vladimir

Re: [PATCH] block-mq: set both block queue and hardware queue restart bit for restart

On Thu, 2017-04-06 at 03:38 +, Long Li wrote: > > -Original Message- > > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > > > > Please drop this patch. I'm working on a better solution. > > Thank you. Looking forward to your patch. Hello Long, It would help if you could

Re: [PATCH] block-mq: set both block queue and hardware queue restart bit for restart

On Thu, 2017-04-06 at 03:38 +, Long Li wrote: > > -Original Message- > > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > > > > Please drop this patch. I'm working on a better solution. > > Thank you. Looking forward to your patch. Hello Long, It would help if you could

Re: [PATCH v3] Allow user probes on versioned symbols

On 04/04/2017 09:26 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Apr 04, 2017 at 11:18:02PM +0900, Masami Hiramatsu escreveu: On Mon, 3 Apr 2017 11:46:58 -0300 Arnaldo Carvalho de Melo wrote: > > > But apart from those problems, I think that one should be able to ask > > > for

Re: [PATCH v3] Allow user probes on versioned symbols

On 04/04/2017 09:26 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Apr 04, 2017 at 11:18:02PM +0900, Masami Hiramatsu escreveu: On Mon, 3 Apr 2017 11:46:58 -0300 Arnaldo Carvalho de Melo wrote: > > > But apart from those problems, I think that one should be able to ask > > > for a versioned

RE: [PATCH] block-mq: set both block queue and hardware queue restart bit for restart

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Wednesday, April 5, 2017 5:32 PM > To: linux-kernel@vger.kernel.org; linux-bl...@vger.kernel.org; Long Li > ; ax...@kernel.dk > Cc: Stephen Hemminger ;

RE: [PATCH] block-mq: set both block queue and hardware queue restart bit for restart

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Wednesday, April 5, 2017 5:32 PM > To: linux-kernel@vger.kernel.org; linux-bl...@vger.kernel.org; Long Li > ; ax...@kernel.dk > Cc: Stephen Hemminger ; KY Srinivasan > ; Long Li > Subject: Re:

[PATCH v5 1/2] module: verify address is read-only

Implement a mechanism to check if a module's address is in the rodata or ro_after_init sections. It mimics the existing functions that test if an address is inside a module's text section. Functions that take a module as an argument will be able to verify that the module address is in a read-only

[PATCH v5 2/2] extable: verify address is read-only

Provide a mechanism to check if the address of a variable is const or ro_after_init. It mimics the existing functions that test if an address is inside the kernel's text section. The idea is to prevent structures that are not read-only from being passed to functions. Other functions inside the

[PATCH v5 2/2] extable: verify address is read-only

Provide a mechanism to check if the address of a variable is const or ro_after_init. It mimics the existing functions that test if an address is inside the kernel's text section. The idea is to prevent structures that are not read-only from being passed to functions. Other functions inside the

[PATCH v5 1/2] module: verify address is read-only

Implement a mechanism to check if a module's address is in the rodata or ro_after_init sections. It mimics the existing functions that test if an address is inside a module's text section. Functions that take a module as an argument will be able to verify that the module address is in a read-only

[PATCH v5 0/2] provide check for ro_after_init memory sections

mlinux.lds: add missing VMLINUX_SYMBOL macros") The latest version of this series uses new symbols provided in these fixes. The series now cross compiles on Blackfin without errors. I have also test compiled this series on next-20170405 for x86. I have dropped the third patch that uses the

[PATCH v5 0/2] provide check for ro_after_init memory sections

mlinux.lds: add missing VMLINUX_SYMBOL macros") The latest version of this series uses new symbols provided in these fixes. The series now cross compiles on Blackfin without errors. I have also test compiled this series on next-20170405 for x86. I have dropped the third patch that uses the

linux-next: manual merge of the staging tree with the v4l-dvb tree

Hi all, Today's linux-next merge of the staging tree got conflicts in: drivers/staging/media/lirc/lirc_sasem.c drivers/staging/media/lirc/lirc_sir.c between commits: e66267161971 ("[media] rc: promote lirc_sir out of staging") 51bb3fd788cb ("[media] staging: lirc_sasem: remove") from

linux-next: manual merge of the staging tree with the v4l-dvb tree

Hi all, Today's linux-next merge of the staging tree got conflicts in: drivers/staging/media/lirc/lirc_sasem.c drivers/staging/media/lirc/lirc_sir.c between commits: e66267161971 ("[media] rc: promote lirc_sir out of staging") 51bb3fd788cb ("[media] staging: lirc_sasem: remove") from

[PATCH v4] tools/perf: Allow user probes on versioned symbols

Symbol versioning, as in glibc, results in symbols being defined as: @[@] (Note that "@@" identifies a default symbol, if the symbol name is repeated.) perf is currently unable to deal with this, and is unable to create user probes at such symbols: -- $ nm

[PATCH v4] tools/perf: Allow user probes on versioned symbols

Symbol versioning, as in glibc, results in symbols being defined as: @[@] (Note that "@@" identifies a default symbol, if the symbol name is repeated.) perf is currently unable to deal with this, and is unable to create user probes at such symbols: -- $ nm

Re: [PATCH] get_maintainer: Add Yakir Yang to .get_maintainer.ignore

Hi Joe, On 04/06/2017 10:39 AM, Joe Perches wrote: On Thu, 2017-04-06 at 10:01 +0800, Jeffy Chen wrote: The mail account "Yakir Yang " is no longer valid. Does this person still want to be involved with the kernel? If so, perhaps a .mailmap entry would be more

Re: [PATCH] get_maintainer: Add Yakir Yang to .get_maintainer.ignore

Hi Joe, On 04/06/2017 10:39 AM, Joe Perches wrote: On Thu, 2017-04-06 at 10:01 +0800, Jeffy Chen wrote: The mail account "Yakir Yang " is no longer valid. Does this person still want to be involved with the kernel? If so, perhaps a .mailmap entry would be more appropriate. i don't think he

Re: [PATCH v2 00/11] fujitsu-laptop: backlight cleanup

On Thu, Apr 06, 2017 at 10:15:14AM +0930, Jonathan Woithe wrote: > Hi Michael > > On Wed, Apr 05, 2017 at 09:55:34PM +0200, Micha?? K??pie?? wrote: > > > On Wed, Apr 05, 2017 at 08:48:59AM +0200, Micha?? K??pie?? wrote: > > > > This series introduces further changes to the way LCD backlight is >

Re: [PATCH v2 00/11] fujitsu-laptop: backlight cleanup

On Thu, Apr 06, 2017 at 10:15:14AM +0930, Jonathan Woithe wrote: > Hi Michael > > On Wed, Apr 05, 2017 at 09:55:34PM +0200, Micha?? K??pie?? wrote: > > > On Wed, Apr 05, 2017 at 08:48:59AM +0200, Micha?? K??pie?? wrote: > > > > This series introduces further changes to the way LCD backlight is >

Re: [RFC net-next] bpf: taint loading !is_gpl programs

Hi Daniel, Daniel Borkmann writes: > On 04/04/2017 08:33 PM, Aaron Conole wrote: >> The eBPF framework is used for more than just socket level filtering. It >> can also provide tracing, and even change the way packets coming into the >> system look. Most of the eBPF

Re: [RFC net-next] bpf: taint loading !is_gpl programs

Hi Daniel, Daniel Borkmann writes: > On 04/04/2017 08:33 PM, Aaron Conole wrote: >> The eBPF framework is used for more than just socket level filtering. It >> can also provide tracing, and even change the way packets coming into the >> system look. Most of the eBPF callable symbols are

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Thu, Apr 06, 2017 at 10:02:48AM +1000, NeilBrown wrote: > If you are concerned about space in 'struct address_space', just prune > some wastage. I'm trying to (via wlists). still buggy though. > The "host" field brings no value. It is only ever assigned in > inode_init_always(): > >

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Thu, Apr 06, 2017 at 10:02:48AM +1000, NeilBrown wrote: > If you are concerned about space in 'struct address_space', just prune > some wastage. I'm trying to (via wlists). still buggy though. > The "host" field brings no value. It is only ever assigned in > inode_init_always(): > >

Re: [PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid

Hi Sean, On 04/06/2017 12:28 AM, Sean Paul wrote: On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote: After unbinding drm, the userspace may still has a chance to access gem buf. Add a sanity check for a NULL dev_private to prevent that from happening. I still don't understand how

Re: [PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid

Hi Sean, On 04/06/2017 12:28 AM, Sean Paul wrote: On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote: After unbinding drm, the userspace may still has a chance to access gem buf. Add a sanity check for a NULL dev_private to prevent that from happening. I still don't understand how

[lkp-robot] [debug] 19d436268d: BUG:unable_to_handle_kernel

FYI, we noticed the following commit: commit: 19d436268dde95389c616bb3819da73f0a8b28a8 ("debug: Add _ONCE() logic to report_bug()") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G

[lkp-robot] [debug] 19d436268d: BUG:unable_to_handle_kernel

FYI, we noticed the following commit: commit: 19d436268dde95389c616bb3819da73f0a8b28a8 ("debug: Add _ONCE() logic to report_bug()") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G

  1   2   3   4   5   6   7   8   9   10   >