[PATCH] Staging : wlan-ng: fix unnecessary parentheses in prism2mgmt.c

This patch fixes up unnecessary parentheses warning found by checkpatch.pl script. Signed-off-by: Yash Omer --- drivers/staging/wlan-ng/prism2mgmt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/prism2mgmt.c

[PATCH] Staging : wlan-ng: fix unnecessary parentheses in prism2mgmt.c

This patch fixes up unnecessary parentheses warning found by checkpatch.pl script. Signed-off-by: Yash Omer --- drivers/staging/wlan-ng/prism2mgmt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/prism2mgmt.c b/drivers/staging/wlan-ng/prism2mgmt.c

Re: [PATCH] perf report: Fix a memory corrupton issue when enabling --branch-history

On Fri, Feb 16, 2018 at 10:25:31AM +0800, Jin, Yao wrote: SNIP > > From my opinion, the option '--max-stack' in perf report looks not very > > necessary. While it's just my personal opinion, need to hear from more > > people. :) > > > > Thanks > > Jin Yao > > > > > thanks, > > > jirka > > >

Re: [PATCH] perf report: Fix a memory corrupton issue when enabling --branch-history

On Fri, Feb 16, 2018 at 10:25:31AM +0800, Jin, Yao wrote: SNIP > > From my opinion, the option '--max-stack' in perf report looks not very > > necessary. While it's just my personal opinion, need to hear from more > > people. :) > > > > Thanks > > Jin Yao > > > > > thanks, > > > jirka > > >

Re: [PATCH 11/12] i2c: qup: reorganization of driver code to remove polling for qup v1

Hi Abhishek, On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > Following are the major issues in current driver code > > 1. The current driver simply assumes the transfer completion >whenever its gets any non-error interrupts and then simply do the >polling of available/free bytes in FIFO. >

Re: [PATCH 11/12] i2c: qup: reorganization of driver code to remove polling for qup v1

Hi Abhishek, On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > Following are the major issues in current driver code > > 1. The current driver simply assumes the transfer completion >whenever its gets any non-error interrupts and then simply do the >polling of available/free bytes in FIFO. >

[RFC PATCH] ptr_ring: linked list fallback

So pointer rings work fine, but they have a problem: make them too small and not enough entries fit. Make them too large and you start flushing your cache and running out of memory. This is a new idea of mine: a ring backed by a linked list. Once you run out of rin entries, instead of a drop you

[RFC PATCH] ptr_ring: linked list fallback

So pointer rings work fine, but they have a problem: make them too small and not enough entries fit. Make them too large and you start flushing your cache and running out of memory. This is a new idea of mine: a ring backed by a linked list. Once you run out of rin entries, instead of a drop you

[PATCH] Staging: wlan-ng: fix unnecessary parantheses in prism2mgmt.c

This patch fixes up a unncessary paratheses warning found by checkpatch.pl script. Signed-off-by: Yash Omer --- drivers/staging/wlan-ng/prism2mgmt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/prism2mgmt.c

[PATCH] Staging: wlan-ng: fix unnecessary parantheses in prism2mgmt.c

This patch fixes up a unncessary paratheses warning found by checkpatch.pl script. Signed-off-by: Yash Omer --- drivers/staging/wlan-ng/prism2mgmt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/prism2mgmt.c b/drivers/staging/wlan-ng/prism2mgmt.c

Re: [PATCH v3 01/11] watchdog/hpwdt: Remove legacy NMI sourcing.

* Jerry Hoemann wrote: > Gen8 and prior Proliant systems supported the "CRU" interface > to firmware. This interfaces allows linux to "call back" into firmware > to source the cause of an NMI. This feature isn't fully utilized > as the actual source of the NMI isn't

Re: [PATCH v3 01/11] watchdog/hpwdt: Remove legacy NMI sourcing.

* Jerry Hoemann wrote: > Gen8 and prior Proliant systems supported the "CRU" interface > to firmware. This interfaces allows linux to "call back" into firmware > to source the cause of an NMI. This feature isn't fully utilized > as the actual source of the NMI isn't printed, the driver only >

Re: [PATCH v2 11/16] mmc: sdhci: Program a relatively accurate SW timeout value

On Monday 05 February 2018 06:20 PM, Kishon Vijay Abraham I wrote: > sdhci has a 10 second timeout to catch devices that stop responding. > Instead of programming 10 second arbitrary value, calculate the total time > it would take for the entire transfer to happen and program the timeout > value

Re: [PATCH v2 11/16] mmc: sdhci: Program a relatively accurate SW timeout value

On Monday 05 February 2018 06:20 PM, Kishon Vijay Abraham I wrote: > sdhci has a 10 second timeout to catch devices that stop responding. > Instead of programming 10 second arbitrary value, calculate the total time > it would take for the entire transfer to happen and program the timeout > value

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

On Thu, Feb 15, 2018 at 11:29:42PM +, Andy Lutomirski wrote: ... > >>> +bool pti_handle_segment_not_present(long error_code) > >>> +{ > >>> + if (!static_cpu_has(X86_FEATURE_PTI)) > >>> + return false; > >>> + > >>> + if ((unsigned short)error_code !=

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

On Thu, Feb 15, 2018 at 11:29:42PM +, Andy Lutomirski wrote: ... > >>> +bool pti_handle_segment_not_present(long error_code) > >>> +{ > >>> + if (!static_cpu_has(X86_FEATURE_PTI)) > >>> + return false; > >>> + > >>> + if ((unsigned short)error_code !=

Re: [PATCH] usb: musb: fix enumeration after resume

On Wed, 7 Feb 2018 14:37:00 -0600 Bin Liu wrote: > On Tue, Feb 06, 2018 at 08:00:24PM +0100, Andreas Kemnade wrote: > > Hi, > > > > On Tue, 6 Feb 2018 12:46:05 -0600 > > Bin Liu wrote: > > > > > Hi, > > > > > > On Sat, Jan 27, 2018 at 09:34:03AM +0100, Andreas

Re: [PATCH] usb: musb: fix enumeration after resume

On Wed, 7 Feb 2018 14:37:00 -0600 Bin Liu wrote: > On Tue, Feb 06, 2018 at 08:00:24PM +0100, Andreas Kemnade wrote: > > Hi, > > > > On Tue, 6 Feb 2018 12:46:05 -0600 > > Bin Liu wrote: > > > > > Hi, > > > > > > On Sat, Jan 27, 2018 at 09:34:03AM +0100, Andreas Kemnade wrote: > > > > On

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

Am Mittwoch, 14. Februar 2018, 21:08:59 CET schrieb Jernej Skrabec: > dw_hdmi shouldn't set drvdata since some drivers might need to store > it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi > instead to store it in drvdata. This way drivers are responsible to > store and pass

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

Am Mittwoch, 14. Februar 2018, 21:08:59 CET schrieb Jernej Skrabec: > dw_hdmi shouldn't set drvdata since some drivers might need to store > it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi > instead to store it in drvdata. This way drivers are responsible to > store and pass

Re: [PATCH 5/8] lightnvm: implement get log report chunk helpers

> On 15 Feb 2018, at 04.51, Matias Bjørling wrote: > > On 02/13/2018 03:06 PM, Javier González wrote: >> From: Javier González >> The 2.0 spec provides a report chunk log page that can be retrieved >> using the stangard nvme get log page. This replaces the

Re: [PATCH 5/8] lightnvm: implement get log report chunk helpers

> On 15 Feb 2018, at 04.51, Matias Bjørling wrote: > > On 02/13/2018 03:06 PM, Javier González wrote: >> From: Javier González >> The 2.0 spec provides a report chunk log page that can be retrieved >> using the stangard nvme get log page. This replaces the dedicated >> get/put bad block table

Re: [PATCH 4.4 000/108] 4.4.116-stable review

On Thu, Feb 15, 2018 at 07:45:08PM -0700, Nathan Chancellor wrote: > On Thu, Feb 15, 2018 at 04:15:57PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.116 release. > > There are 108 patches in this series, all will be posted as a response > > to this

Re: [PATCH 4.4 000/108] 4.4.116-stable review

On Thu, Feb 15, 2018 at 07:45:08PM -0700, Nathan Chancellor wrote: > On Thu, Feb 15, 2018 at 04:15:57PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.116 release. > > There are 108 patches in this series, all will be posted as a response > > to this

Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

On Thu, Feb 15, 2018 at 06:31:48PM -0800, Brian Norris wrote: > On Thu, Feb 15, 2018 at 04:17:32PM +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > Consider this an objection: > > I'm currently arguing that this is unnecessarily

Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

On Thu, Feb 15, 2018 at 06:31:48PM -0800, Brian Norris wrote: > On Thu, Feb 15, 2018 at 04:17:32PM +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > Consider this an objection: > > I'm currently arguing that this is unnecessarily

Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect

> On 15 Feb 2018, at 05.11, Matias Bjørling wrote: > > The value of max_phys_sect is always static. Instead of > defining it in the nvm_dev_ops structure, declare it as a global > value. > > Signed-off-by: Matias Bjørling > --- > drivers/lightnvm/core.c

Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect

> On 15 Feb 2018, at 05.11, Matias Bjørling wrote: > > The value of max_phys_sect is always static. Instead of > defining it in the nvm_dev_ops structure, declare it as a global > value. > > Signed-off-by: Matias Bjørling > --- > drivers/lightnvm/core.c | 28

Re: [PATCH 6/8] lightnvm: pblk: implement get log report chunk

> On 15 Feb 2018, at 02.59, Matias Bjørling wrote: > > On 02/13/2018 03:06 PM, Javier González wrote: >> From: Javier González >> In preparation of pblk supporting 2.0, implement the get log report >> chunk in pblk. >> This patch only replicates de bad

Re: [PATCH 6/8] lightnvm: pblk: implement get log report chunk

> On 15 Feb 2018, at 02.59, Matias Bjørling wrote: > > On 02/13/2018 03:06 PM, Javier González wrote: >> From: Javier González >> In preparation of pblk supporting 2.0, implement the get log report >> chunk in pblk. >> This patch only replicates de bad block functionality as the rest of the >>

Re: [PATCH 2/8] lightnvm: show generic geometry in sysfs

> On 15 Feb 2018, at 02.20, Matias Bjørling wrote: > > On 02/13/2018 03:06 PM, Javier González wrote: >> From: Javier González >> Apart from showing the geometry returned by the different identify >> commands, provide the generic geometry too, as this is

Re: [PATCH 2/8] lightnvm: show generic geometry in sysfs

> On 15 Feb 2018, at 02.20, Matias Bjørling wrote: > > On 02/13/2018 03:06 PM, Javier González wrote: >> From: Javier González >> Apart from showing the geometry returned by the different identify >> commands, provide the generic geometry too, as this is the geometry that >> targets will use

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

On 2018-02-15 18:19, Richard Guy Briggs wrote: > On 2018-02-15 18:07, Steve Grubb wrote: > > On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote: > > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > > records to be associated with the init_module and

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

On 2018-02-15 18:19, Richard Guy Briggs wrote: > On 2018-02-15 18:07, Steve Grubb wrote: > > On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote: > > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > > records to be associated with the init_module and

[PATCH v4 0/4] Add DTS for SDM845 SoC and MTP

These are basic device tree files needed to boot a SDM845 MTP board to a ramfs based serial console shell Bindings are based on whats proposed for pinctrl/serial/clock drivers for SDM845 SoC pinctrl: https://patchwork.kernel.org/patch/10157143/ (This is now pulled in by Linus Walleij for 4.17)

[PATCH v4 0/4] Add DTS for SDM845 SoC and MTP

These are basic device tree files needed to boot a SDM845 MTP board to a ramfs based serial console shell Bindings are based on whats proposed for pinctrl/serial/clock drivers for SDM845 SoC pinctrl: https://patchwork.kernel.org/patch/10157143/ (This is now pulled in by Linus Walleij for 4.17)

[PATCH v4 4/4] arm64: dts: sdm845: Add serial console support

Add the qup uart node and geni se instance needed to support the serial console on the MTP. Signed-off-by: Rajendra Nayak --- arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 39 + arch/arm64/boot/dts/qcom/sdm845.dtsi| 39

[PATCH v4 4/4] arm64: dts: sdm845: Add serial console support

Add the qup uart node and geni se instance needed to support the serial console on the MTP. Signed-off-by: Rajendra Nayak --- arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 39 + arch/arm64/boot/dts/qcom/sdm845.dtsi| 39 + 2 files

[PATCH v4 2/4] dt-bindings: qcom: Add SDM845 bindings

Add a SoC string 'sdm845' for the qualcomm SDM845 SoC Signed-off-by: Rajendra Nayak --- Documentation/devicetree/bindings/arm/qcom.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.txt

[PATCH v4 2/4] dt-bindings: qcom: Add SDM845 bindings

Add a SoC string 'sdm845' for the qualcomm SDM845 SoC Signed-off-by: Rajendra Nayak --- Documentation/devicetree/bindings/arm/qcom.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.txt b/Documentation/devicetree/bindings/arm/qcom.txt index

[PATCH v4 3/4] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP

Add a skeletal sdm845 SoC dtsi and MTP board dts/dtsi files Signed-off-by: Rajendra Nayak Reviewed-by: Doug Anderson --- arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 15 ++

[PATCH v4 1/4] dt-bindings: arm: Document kryo385 cpu

Document the compatible string for the Kryo385 cpus found in qualcomm SoCs. Signed-off-by: Rajendra Nayak Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/cpus.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v4 3/4] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP

Add a skeletal sdm845 SoC dtsi and MTP board dts/dtsi files Signed-off-by: Rajendra Nayak Reviewed-by: Doug Anderson --- arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 15 ++ arch/arm64/boot/dts/qcom/sdm845.dtsi| 277

[PATCH v4 1/4] dt-bindings: arm: Document kryo385 cpu

Document the compatible string for the Kryo385 cpus found in qualcomm SoCs. Signed-off-by: Rajendra Nayak Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/cpus.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

On 2018-02-15 18:07, Steve Grubb wrote: > On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote: > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > records to be associated with the init_module and finit_module SYSCALL > > records on a few modules when the

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

On 2018-02-15 18:07, Steve Grubb wrote: > On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote: > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > records to be associated with the init_module and finit_module SYSCALL > > records on a few modules when the

Re: [PATCH 4.15 000/202] 4.15.4-stable review

On 15 February 2018 at 20:45, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.4 release. > There are 202 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH 4.15 000/202] 4.15.4-stable review

On 15 February 2018 at 20:45, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.4 release. > There are 202 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > >

Re: [PATCH 4.9 00/88] 4.9.82-stable review

On 15 February 2018 at 20:46, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.82 release. > There are 88 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH 4.14 000/195] 4.14.20-stable review

On 15 February 2018 at 20:44, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.20 release. > There are 195 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH 4.9 00/88] 4.9.82-stable review

On 15 February 2018 at 20:46, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.82 release. > There are 88 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > >

Re: [PATCH 4.14 000/195] 4.14.20-stable review

On 15 February 2018 at 20:44, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.20 release. > There are 195 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > >

Re: [PATCH 4.4 000/108] 4.4.116-stable review

-tests - skip: 1, pass: 12, Hikey results summary, Summary kernel: 4.4.116-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git tag: 4.4.116-rc1-hikey-20180215-131 git commit: 4da825751e43ebd33e27ce2b70f1ede852310a87 git descri

Re: [PATCH 4.4 000/108] 4.4.116-stable review

- skip: 1, pass: 12, Hikey results summary, Summary kernel: 4.4.116-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git tag: 4.4.116-rc1-hikey-20180215-131 git commit: 4da825751e43ebd33e27ce2b70f1ede852310a87 git describe: 4.4.116-rc1-hikey-20180215-131 Test det

[git pull] drm fixes for 4.16-rc2

Hi Linus, One nouveau regression fix, one AMD quirk and a full set of i915 fixes. The i915 fixes are mostly for things caught by their CI system, main ones being DSI panel fixes and GEM fixes. Pretty quiet overall. Dave. The following changes since commit

[git pull] drm fixes for 4.16-rc2

Hi Linus, One nouveau regression fix, one AMD quirk and a full set of i915 fixes. The i915 fixes are mostly for things caught by their CI system, main ones being DSI panel fixes and GEM fixes. Pretty quiet overall. Dave. The following changes since commit

Re: [PATCH 10/12] i2c: qup: send NACK for last read sub transfers

Hi Abhishek, On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > According to I2c specification, “If a master-receiver sends a > repeated START condition, it sends a not-acknowledge (A) just > before the repeated START condition”. QUP v2 supports sending > of NACK without stop with QUP_TAG_V2_DATARD_NACK

Re: [PATCH 10/12] i2c: qup: send NACK for last read sub transfers

Hi Abhishek, On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > According to I2c specification, “If a master-receiver sends a > repeated START condition, it sends a not-acknowledge (A) just > before the repeated START condition”. QUP v2 supports sending > of NACK without stop with QUP_TAG_V2_DATARD_NACK

Re: [PATCH v4 0/8] ARM: sun9i: SMP and CPU hotplug support

On Tue, Feb 13, 2018 at 4:15 PM, Chen-Yu Tsai wrote: > Hi Nicolas, Dave, > > On Wed, Jan 17, 2018 at 4:46 PM, Chen-Yu Tsai wrote: >> This is v4 of my sun9i SMP/hotplug support series which was started >> over two years ago [1]. We've tried to implement PSCI for both

Re: [PATCH v4 0/8] ARM: sun9i: SMP and CPU hotplug support

On Tue, Feb 13, 2018 at 4:15 PM, Chen-Yu Tsai wrote: > Hi Nicolas, Dave, > > On Wed, Jan 17, 2018 at 4:46 PM, Chen-Yu Tsai wrote: >> This is v4 of my sun9i SMP/hotplug support series which was started >> over two years ago [1]. We've tried to implement PSCI for both the A80 >> and A83T. Results

[PATCH v2 1/1] usb: cdc_acm: prevent race at write to acm while system resumes

From: Dominik Bozek ACM driver may accept data to transmit while system is not fully resumed. In this case ACM driver buffers data and prepare URBs on usb anchor list. There is a little chance that two tasks put a char and initiate acm_tty_flush_chars(). In such a case,

[PATCH v2 1/1] usb: cdc_acm: prevent race at write to acm while system resumes

From: Dominik Bozek ACM driver may accept data to transmit while system is not fully resumed. In this case ACM driver buffers data and prepare URBs on usb anchor list. There is a little chance that two tasks put a char and initiate acm_tty_flush_chars(). In such a case, driver will put one URB

Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len

Hi Abhishek, On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > The BAM mode requires buffer for start tag data and tx, rx SG > list. Currently, this is being taken for maximum transfer length > (65K). But an I2C transfer can have multiple messages and each > message can be of this maximum length so the

Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len

Hi Abhishek, On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > The BAM mode requires buffer for start tag data and tx, rx SG > list. Currently, this is being taken for maximum transfer length > (65K). But an I2C transfer can have multiple messages and each > message can be of this maximum length so the

Re: [PATCH v4 4/5] x86/apic: Rename variable/function related to x86_io_apic_ops

Hi Baoquan, I love your patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.16-rc1 next-20180215] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH v4 4/5] x86/apic: Rename variable/function related to x86_io_apic_ops

Hi Baoquan, I love your patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.16-rc1 next-20180215] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH 1/3] dt-bindings: aspeed-lpc: Document LPC Host Interface Controller

On Mon, 2018-02-12 at 17:38 +1030, Joel Stanley wrote: > The LPC Host Interface Controller is part of a BMC SoC that is used for > communication with the host. > > Signed-off-by: Joel Stanley > --- > .../devicetree/bindings/mfd/aspeed-lpc.txt | 40 >

Re: [PATCH 1/3] dt-bindings: aspeed-lpc: Document LPC Host Interface Controller

On Mon, 2018-02-12 at 17:38 +1030, Joel Stanley wrote: > The LPC Host Interface Controller is part of a BMC SoC that is used for > communication with the host. > > Signed-off-by: Joel Stanley > --- > .../devicetree/bindings/mfd/aspeed-lpc.txt | 40 > ++ > 1 file

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote: dw_hdmi shouldn't set drvdata since some drivers might need to store it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi instead to store it in drvdata. This way drivers are responsible to store and pass structure

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote: dw_hdmi shouldn't set drvdata since some drivers might need to store it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi instead to store it in drvdata. This way drivers are responsible to store and pass structure

Re: [PATCH v5 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote: Parts of PHY code could be useful also for custom PHYs. For example, Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY with few additional memory mapped registers, so most of the Synopsys PHY related code could be

Re: [PATCH v5 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote: Parts of PHY code could be useful also for custom PHYs. For example, Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY with few additional memory mapped registers, so most of the Synopsys PHY related code could be

Re: [PATCH v5 03/12] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote: Allwinner SoCs have dw hdmi controller v1.32a which exhibits same magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it. Tests show that one iteration is enough. Acked-by: Laurent Pinchart

Re: [PATCH v5 03/12] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote: Allwinner SoCs have dw hdmi controller v1.32a which exhibits same magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it. Tests show that one iteration is enough. Acked-by: Laurent Pinchart Reviewed-by: Archit Taneja

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

Andy Lutomirski wrote: > On Fri, Feb 16, 2018 at 12:42 AM, Linus Torvalds > wrote: >> On Thu, Feb 15, 2018 at 4:22 PM, Nadav Amit wrote: >>> It is not too pretty, I agree, but it should do the work. There is only one >>>

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

Andy Lutomirski wrote: > On Fri, Feb 16, 2018 at 12:42 AM, Linus Torvalds > wrote: >> On Thu, Feb 15, 2018 at 4:22 PM, Nadav Amit wrote: >>> It is not too pretty, I agree, but it should do the work. There is only one >>> problematic descriptor that can be used to switch from compatibility-mode

Re: [RFC 1/2] sched: reduce migration cost between faster caches for idle_balance

On Thu, 2018-02-15 at 10:07 -0800, Rohit Jain wrote: > > > Rohit is running more tests with a patch that deletes > > sysctl_sched_migration_cost from idle_balance, and for his patch but > > with the 5000 usec mistake corrected back to 500 usec. So far both > > give improvements over the

Re: [PATCH 3/3] taint: Add taint for randstruct

On Thu, Feb 15, 2018 at 07:37:44PM -0800, Kees Cook wrote: > + [ TAINT_RANDSTRUCT ]= { 'T', ' ', true }, Something like this, yeah.

Re: [RFC 1/2] sched: reduce migration cost between faster caches for idle_balance

On Thu, 2018-02-15 at 10:07 -0800, Rohit Jain wrote: > > > Rohit is running more tests with a patch that deletes > > sysctl_sched_migration_cost from idle_balance, and for his patch but > > with the 5000 usec mistake corrected back to 500 usec. So far both > > give improvements over the

Re: [PATCH 3/3] taint: Add taint for randstruct

On Thu, Feb 15, 2018 at 07:37:44PM -0800, Kees Cook wrote: > + [ TAINT_RANDSTRUCT ]= { 'T', ' ', true }, Something like this, yeah.

Re: [PATCH 08/12] i2c: qup: change completion timeout according to transfer length

On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > Currently the completion timeout is being taken according to > maximum transfer length which is too high if SCL is operating in > high frequency. This patch calculates timeout on the basis of > one-byte transfer time and uses the same for completion

Re: [PATCH 08/12] i2c: qup: change completion timeout according to transfer length

On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > Currently the completion timeout is being taken according to > maximum transfer length which is too high if SCL is operating in > high frequency. This patch calculates timeout on the basis of > one-byte transfer time and uses the same for completion

Re: [PATCH -mm 1/3] proc: randomize "struct pde_opener"

On Fri, Feb 16, 2018 at 12:13:17AM +, Al Viro wrote: > On Fri, Feb 16, 2018 at 12:41:13AM +0300, Alexey Dobriyan wrote: > > On Thu, Feb 15, 2018 at 07:07:13PM +, Al Viro wrote: > > > On Wed, Feb 14, 2018 at 11:19:35AM +0300, Alexey Dobriyan wrote: > > > > > > > The more the merrier. > > >

Re: [PATCH -mm 1/3] proc: randomize "struct pde_opener"

On Fri, Feb 16, 2018 at 12:13:17AM +, Al Viro wrote: > On Fri, Feb 16, 2018 at 12:41:13AM +0300, Alexey Dobriyan wrote: > > On Thu, Feb 15, 2018 at 07:07:13PM +, Al Viro wrote: > > > On Wed, Feb 14, 2018 at 11:19:35AM +0300, Alexey Dobriyan wrote: > > > > > > > The more the merrier. > > >

Re: [PATCH -mm 1/3] proc: randomize "struct pde_opener"

On Thu, Feb 15, 2018 at 04:53:29PM -0800, Kees Cook wrote: > On Wed, Feb 14, 2018 at 12:19 AM, Alexey Dobriyan wrote: > > The more the merrier. > > What made you choose this structure, BTW? Nothing depends on its layout. No funky memcpy/memset... It is strange you didn't

Re: [PATCH -mm 1/3] proc: randomize "struct pde_opener"

On Thu, Feb 15, 2018 at 04:53:29PM -0800, Kees Cook wrote: > On Wed, Feb 14, 2018 at 12:19 AM, Alexey Dobriyan wrote: > > The more the merrier. > > What made you choose this structure, BTW? Nothing depends on its layout. No funky memcpy/memset... It is strange you didn't annotate like 95% of

Re: [PATCH] mfd: tps65218: Reorder tps65218_regulator_id enum

On Friday 16 February 2018 09:47 AM, Dave Gerlach wrote: > Commit 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles") > changes the probe function of drivers/regulator/tps65218-regulator.c so > that it iterates through all available regulators and assumes that the > regulator IDs

Re: [PATCH] mfd: tps65218: Reorder tps65218_regulator_id enum

On Friday 16 February 2018 09:47 AM, Dave Gerlach wrote: > Commit 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles") > changes the probe function of drivers/regulator/tps65218-regulator.c so > that it iterates through all available regulators and assumes that the > regulator IDs

Re: [PATCH 07/12] i2c: qup: use the complete transfer length to choose DMA mode

On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > Currently each message length in complete transfer is being > checked for determining DMA mode and if any of the message length > is less than FIFO length then non DMA mode is being used which > will increase overhead. DMA can be used for any length

Re: [PATCH 07/12] i2c: qup: use the complete transfer length to choose DMA mode

On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > Currently each message length in complete transfer is being > checked for determining DMA mode and if any of the message length > is less than FIFO length then non DMA mode is being used which > will increase overhead. DMA can be used for any length

Re: [PATCH 06/12] i2c: qup: proper error handling for i2c error in BAM mode

On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > Currently the i2c error handling in BAM mode is not working > properly in stress condition. > > 1. After an error, the FIFO are being written with FLUSH and >EOT tags which should not be required since already these tags >have been written in

Re: [PATCH 06/12] i2c: qup: proper error handling for i2c error in BAM mode

On 2/3/2018 1:28 PM, Abhishek Sahu wrote: > Currently the i2c error handling in BAM mode is not working > properly in stress condition. > > 1. After an error, the FIFO are being written with FLUSH and >EOT tags which should not be required since already these tags >have been written in

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

> > + wrmsrl(MSR_IA32_PRED_CMD, PRED_CMD_IBPB); > > Should this be wrmsrl_safe? I don't see where we've verified host > support of this MSR. In mainline all wrmsr are wrmsrl_safe now. -Andi

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

> > + wrmsrl(MSR_IA32_PRED_CMD, PRED_CMD_IBPB); > > Should this be wrmsrl_safe? I don't see where we've verified host > support of this MSR. In mainline all wrmsr are wrmsrl_safe now. -Andi

[PATCH] mfd: tps65218: Reorder tps65218_regulator_id enum

Commit 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles") changes the probe function of drivers/regulator/tps65218-regulator.c so that it iterates through all available regulators and assumes that the regulator IDs are sequential and match the order present in the enum

[PATCH] mfd: tps65218: Reorder tps65218_regulator_id enum

Commit 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles") changes the probe function of drivers/regulator/tps65218-regulator.c so that it iterates through all available regulators and assumes that the regulator IDs are sequential and match the order present in the enum

Re: [PATCH 8/9] KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Tue, Feb 6, 2018 at 9:29 AM, David Woodhouse wrote: > @@ -8946,6 +9017,27 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu > *vcpu) > #endif > ); > > + /* > +* We do not use IBRS in the kernel. If this vCPU has used the > +*

Re: [PATCH 8/9] KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Tue, Feb 6, 2018 at 9:29 AM, David Woodhouse wrote: > @@ -8946,6 +9017,27 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu > *vcpu) > #endif > ); > > + /* > +* We do not use IBRS in the kernel. If this vCPU has used the > +* SPEC_CTRL MSR it may have

Re: [PATCH v3] rtc: ac100: Fix ac100 determine rate bug

On Fri, Feb 16, 2018 at 1:53 AM, Philipp Rossak wrote: > > > On 15.02.2018 15:11, Maxime Ripard wrote: >> >> On Wed, Feb 14, 2018 at 02:56:12PM +0100, Philipp Rossak wrote: >>> >>> This patch fixes a bug, that prevents the Allwinner A83T and the A80 >>> from a successful boot.

Re: [PATCH v3] rtc: ac100: Fix ac100 determine rate bug

On Fri, Feb 16, 2018 at 1:53 AM, Philipp Rossak wrote: > > > On 15.02.2018 15:11, Maxime Ripard wrote: >> >> On Wed, Feb 14, 2018 at 02:56:12PM +0100, Philipp Rossak wrote: >>> >>> This patch fixes a bug, that prevents the Allwinner A83T and the A80 >>> from a successful boot. >>> >>> The bug is

  1   2   3   4   5   6   7   8   9   10   >