Re: [PATCH v3][manpages 2/2] perf_event_open.2: Document write_backward

Hello Wang Nan, On 10/24/2016 08:52 AM, Wang Nan wrote: > Linux 4.7 (9ecda41acb971ebd07c8fb35faf24005c0baea12) introduces write_backward > attribute to perf_event_attr. Document this feature. > > Signed-off-by: Wang Nan > Reviewed-by: Vince Weaver

Re: [PATCH v4 0/4] MIPS: Remote processor driver

Hi Thomas, On 09/11/16 10:15, Thomas Gleixner wrote: On Wed, 2 Nov 2016, Matt Redfearn wrote: The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs. The CPU must be offlined from Linux first. A sysfs interface is created which

Re: [PATCH v3][manpages 2/2] perf_event_open.2: Document write_backward

Hello Wang Nan, On 10/24/2016 08:52 AM, Wang Nan wrote: > Linux 4.7 (9ecda41acb971ebd07c8fb35faf24005c0baea12) introduces write_backward > attribute to perf_event_attr. Document this feature. > > Signed-off-by: Wang Nan > Reviewed-by: Vince Weaver > Cc: Michael Kerrisk > --- >

Re: [PATCH v4 0/4] MIPS: Remote processor driver

Hi Thomas, On 09/11/16 10:15, Thomas Gleixner wrote: On Wed, 2 Nov 2016, Matt Redfearn wrote: The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs. The CPU must be offlined from Linux first. A sysfs interface is created which

[PATCH] serial: 8250_pxa: hide early console setup when disabled

The newly added pxa glue driver for 8250 supports console output, but fails to build if the 8250 console is disabled: drivers/tty/serial/8250/8250_pxa.o: In function `early_serial_pxa_setup': 8250_pxa.c:(.init.text+0x50): undefined reference to `early_serial8250_setup' This adds an #ifdef like

[PATCH] serial: 8250_pxa: hide early console setup when disabled

The newly added pxa glue driver for 8250 supports console output, but fails to build if the 8250 console is disabled: drivers/tty/serial/8250/8250_pxa.o: In function `early_serial_pxa_setup': 8250_pxa.c:(.init.text+0x50): undefined reference to `early_serial8250_setup' This adds an #ifdef like

[PATCH V2 1/4] soc/tegra: pmc: Remove legacy Tegra I/O rail API

Remove tegra_io_rail_power_on() and tegra_io_rail_power_off() from header as client has been moved to new APIs. Signed-off-by: Laxman Dewangan --- Changes from V1: None --- include/soc/tegra/pmc.h | 10 -- 1 file changed, 10 deletions(-) diff --git

Re: [RFC 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio host controller sub-vended by NI

On 08/11/16 22:07, Zach Brown wrote: > On NI 9037 boards the max SDIO frequency is limited by trace lengths > and other layout choices. The max SDIO frequency is stored in an ACPI > table, as MXFQ. > > The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the > f_max field of the

[PATCH V2 4/4] soc/tegra: pmc: Make configuration of IO pads in atomic context

The IO pad voltage configuration can be done in the regulator notifier callback which is atomic in nature. Replace the mutex with spin lock for the locking mechanism. Signed-off-by: Laxman Dewangan --- Changes from V1: New in series based on pinctrl driver requirement.

[PATCH V2 1/4] soc/tegra: pmc: Remove legacy Tegra I/O rail API

Remove tegra_io_rail_power_on() and tegra_io_rail_power_off() from header as client has been moved to new APIs. Signed-off-by: Laxman Dewangan --- Changes from V1: None --- include/soc/tegra/pmc.h | 10 -- 1 file changed, 10 deletions(-) diff --git a/include/soc/tegra/pmc.h

Re: [RFC 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio host controller sub-vended by NI

On 08/11/16 22:07, Zach Brown wrote: > On NI 9037 boards the max SDIO frequency is limited by trace lengths > and other layout choices. The max SDIO frequency is stored in an ACPI > table, as MXFQ. > > The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the > f_max field of the

[PATCH V2 4/4] soc/tegra: pmc: Make configuration of IO pads in atomic context

The IO pad voltage configuration can be done in the regulator notifier callback which is atomic in nature. Replace the mutex with spin lock for the locking mechanism. Signed-off-by: Laxman Dewangan --- Changes from V1: New in series based on pinctrl driver requirement. ---

[PATCH V2 2/4] soc/tegra: pmc: Add interface to get IO pad power status

Add API to get the IO pad power status of the Tegra IO pads. This will help client driver to get the current power status of IO pads for handling IO pad power. Signed-off-by: Laxman Dewangan --- Changes from V1: None --- drivers/soc/tegra/pmc.c | 22

[PATCH V2 2/4] soc/tegra: pmc: Add interface to get IO pad power status

Add API to get the IO pad power status of the Tegra IO pads. This will help client driver to get the current power status of IO pads for handling IO pad power. Signed-off-by: Laxman Dewangan --- Changes from V1: None --- drivers/soc/tegra/pmc.c | 22 ++

Re: [PATCH v3][manpages 1/2] perf_event_open.2: Document PERF_EVENT_IOC_PAUSE_OUTPUT

Hello Wang Nan, On 10/24/2016 08:52 AM, Wang Nan wrote: > Linux 4.7 (86e7972f690c1017fd086cdfe53d8524e68c661c) introduces > PERF_EVENT_IOC_PAUSE_OUTPUT feature. Document it. > > Signed-off-by: Wang Nan > Reviewed-by: Vince Weaver > Cc: Michael

Re: [PATCH v3][manpages 1/2] perf_event_open.2: Document PERF_EVENT_IOC_PAUSE_OUTPUT

Hello Wang Nan, On 10/24/2016 08:52 AM, Wang Nan wrote: > Linux 4.7 (86e7972f690c1017fd086cdfe53d8524e68c661c) introduces > PERF_EVENT_IOC_PAUSE_OUTPUT feature. Document it. > > Signed-off-by: Wang Nan > Reviewed-by: Vince Weaver > Cc: Michael Kerrisk > --- > man2/perf_event_open.2 | 24

[PATCH V2 3/4] soc/tegra: pmc: Register PMC child devices as platform device

Power Management Controller(PMC) of Tegra does the multiple chip power management related functionality for internal and IO interfacing. Some of the functionalities are power gating of IP blocks, IO pads voltage and power state configuration, system power state configurations, wakeup controls etc.

Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

Thanks Corrina for your info. I tested my patch, it works for me on kernel 4.9-rc4. "surprise removal" maybe another issue to solve. This one is enough to solve my issue and other one's, could it be accept first? Cao jin On 11/09/2016 03:33 AM, Alexander Duyck wrote: On Tue, Nov 8, 2016 at

[PATCH V2 0/4] soc/tegra: pmc: Add support for IO pad configuration and sub-driver

Tegra SoC support the configutaion of IO pads to multi-level voltage and low power state. The conifguration is done via pictrl framework and the io pad driver in pinctrl frameowrk uses the APIs from pmc to access PMC registers. his series add the API to get the IO pad power status and register

Re: [PATCH 1/2] dt-bindings: sound: document axentia,tse850-pcm5142 bindings

On Tue, Nov 08, 2016 at 05:20:56PM +0100, Peter Rosin wrote: > The TSE-850 is an FM Transmitter Station Equipment, designed to generate > baseband signals for FM, mainly the DARC subcarrier, but other signals > are also possible. Please use subject lines matching the style for the subsystem.

[PATCH V2 0/4] soc/tegra: pmc: Add support for IO pad configuration and sub-driver

Tegra SoC support the configutaion of IO pads to multi-level voltage and low power state. The conifguration is done via pictrl framework and the io pad driver in pinctrl frameowrk uses the APIs from pmc to access PMC registers. his series add the API to get the IO pad power status and register

Re: [PATCH 1/2] dt-bindings: sound: document axentia,tse850-pcm5142 bindings

On Tue, Nov 08, 2016 at 05:20:56PM +0100, Peter Rosin wrote: > The TSE-850 is an FM Transmitter Station Equipment, designed to generate > baseband signals for FM, mainly the DARC subcarrier, but other signals > are also possible. Please use subject lines matching the style for the subsystem.

[PATCH V2 3/4] soc/tegra: pmc: Register PMC child devices as platform device

Power Management Controller(PMC) of Tegra does the multiple chip power management related functionality for internal and IO interfacing. Some of the functionalities are power gating of IP blocks, IO pads voltage and power state configuration, system power state configurations, wakeup controls etc.

Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

Thanks Corrina for your info. I tested my patch, it works for me on kernel 4.9-rc4. "surprise removal" maybe another issue to solve. This one is enough to solve my issue and other one's, could it be accept first? Cao jin On 11/09/2016 03:33 AM, Alexander Duyck wrote: On Tue, Nov 8, 2016 at

Is Documentation/networking/phy.txt still up-to-date?

Hi, Documentation/networking/phy.txt discusses phy_connect and states that: "... interface is a u32 which specifies the connection type used between the controller and the PHY. Examples are GMII, MII, RGMII, and SGMII. For a full list, see include/linux/phy.h Now just make sure that

[PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399

From: Mark Yao Add the core display-subsystem node and the two display controllers available on the rk3399. Signed-off-by: Mark Yao Signed-off-by: Yakir Yang Signed-off-by: Caesar Wang --- Changes in

[PATCH v2] MIPS: mm: Fix output of __do_page_fault

Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") the output from __do_page_fault on MIPS has been pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to provide the appropriate markers & restore the expected output. Signed-off-by: Matt

Is Documentation/networking/phy.txt still up-to-date?

Hi, Documentation/networking/phy.txt discusses phy_connect and states that: "... interface is a u32 which specifies the connection type used between the controller and the PHY. Examples are GMII, MII, RGMII, and SGMII. For a full list, see include/linux/phy.h Now just make sure that

[PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399

From: Mark Yao Add the core display-subsystem node and the two display controllers available on the rk3399. Signed-off-by: Mark Yao Signed-off-by: Yakir Yang Signed-off-by: Caesar Wang --- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58

[PATCH v2] MIPS: mm: Fix output of __do_page_fault

Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") the output from __do_page_fault on MIPS has been pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to provide the appropriate markers & restore the expected output. Signed-off-by: Matt

[PATCH v2 5/9] arm64: dts: rockchip: add backlight support for rk3399 evb board

From: Yakir Yang Add backlight node for evb board, perpare for panel device node. Signed-off-by: Yakir Yang Signed-off-by: Caesar Wang --- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40

[PATCH v2 8/9] arm64: dts: rockchip: support dwc3 USB for rk3399

From: Brian Norris Add the dwc3 usb needed node information for rk3399. Signed-off-by: Brian Norris Signed-off-by: Caesar Wang --- Changes in v2: - the original patches from brian posting on

[PATCH v2 5/9] arm64: dts: rockchip: add backlight support for rk3399 evb board

From: Yakir Yang Add backlight node for evb board, perpare for panel device node. Signed-off-by: Yakir Yang Signed-off-by: Caesar Wang --- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 + 1 file changed, 40 insertions(+) diff --git

[PATCH v2 8/9] arm64: dts: rockchip: support dwc3 USB for rk3399

From: Brian Norris Add the dwc3 usb needed node information for rk3399. Signed-off-by: Brian Norris Signed-off-by: Caesar Wang --- Changes in v2: - the original patches from brian posting on https://chromium-review.googlesource.com/343603 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 54

[PATCH v2 6/9] arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node

From: Yakir Yang The pclk_vio_grf supply power for VIO GRF IOs, if it is disabled, driver would failed to operate the VIO GRF registers. Signed-off-by: Yakir Yang Signed-off-by: Caesar Wang --- Changes in v2: None

[PATCH v2 9/9] arm64: dts: rockchip: add the usb3 pd for rk3399

1. add pd node for RK3399 Soc 2. create power domain tree 3. add qos node for domain 4. add the pd support for usb3 Signed-off-by: Caesar Wang --- Changes in v2: - Reviewed-on: https://chromium-review.googlesource.com/384280 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 18

[PATCH v2 7/9] arm64: dts: rockchip: add pd_edp node for rk3399

From: zhangqing 1. add pd node for RK3399 Soc 2. create power domain tree 3. add qos node for domain 4. add the pd support for edp Signed-off-by: Elaine Zhang Signed-off-by: Caesar Wang --- Changes in v2: None

[PATCH V2 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads

NVIDIA Tegra124 and later SoCs support the multi-voltage level and low power state of some of its IO pads. The IO pads can work in the voltage of the 1.8V and 3.3V of IO voltage from IO power rail sources. When IO interfaces are not used then IO pads can be configure in low power state to reduce

[PATCH v2 6/9] arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node

From: Yakir Yang The pclk_vio_grf supply power for VIO GRF IOs, if it is disabled, driver would failed to operate the VIO GRF registers. Signed-off-by: Yakir Yang Signed-off-by: Caesar Wang --- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++-- 1 file changed, 2

[PATCH v2 9/9] arm64: dts: rockchip: add the usb3 pd for rk3399

1. add pd node for RK3399 Soc 2. create power domain tree 3. add qos node for domain 4. add the pd support for usb3 Signed-off-by: Caesar Wang --- Changes in v2: - Reviewed-on: https://chromium-review.googlesource.com/384280 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 18 ++ 1

[PATCH v2 7/9] arm64: dts: rockchip: add pd_edp node for rk3399

From: zhangqing 1. add pd node for RK3399 Soc 2. create power domain tree 3. add qos node for domain 4. add the pd support for edp Signed-off-by: Elaine Zhang Signed-off-by: Caesar Wang --- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 + 1 file changed, 5

[PATCH V2 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads

NVIDIA Tegra124 and later SoCs support the multi-voltage level and low power state of some of its IO pads. The IO pads can work in the voltage of the 1.8V and 3.3V of IO voltage from IO power rail sources. When IO interfaces are not used then IO pads can be configure in low power state to reduce

[PATCH V2 1/2] pinctrl: tegra: Add DT binding for io pads control

NVIDIA Tegra124 and later SoCs support the multi-voltage level and low power state of some of its IO pads. The IO pads can work in the voltage of the 1.8V and 3.3V of IO voltage from IO power rail sources. When IO interfaces are not used then IO pads can be configure in low power state to reduce

Re: [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration

Hi Lorenzo, On 18.10.2016 18:04, Lorenzo Pieralisi wrote: In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure

[PATCH V2 1/2] pinctrl: tegra: Add DT binding for io pads control

NVIDIA Tegra124 and later SoCs support the multi-voltage level and low power state of some of its IO pads. The IO pads can work in the voltage of the 1.8V and 3.3V of IO voltage from IO power rail sources. When IO interfaces are not used then IO pads can be configure in low power state to reduce

Re: [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration

Hi Lorenzo, On 18.10.2016 18:04, Lorenzo Pieralisi wrote: In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure

[PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399

From: zhangqing 1.add pd node for RK3399 Soc 2.create power domain tree 3.add qos node for domain 4.add the pd_sd consumers node Signed-off-by: Elaine Zhang Signed-off-by: Caesar Wang --- Changes in v2: - v1 on

[PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399

From: zhangqing 1.add pd node for RK3399 Soc 2.create power domain tree 3.add qos node for domain 4.add the pd_sd consumers node Signed-off-by: Elaine Zhang Signed-off-by: Caesar Wang --- Changes in v2: - v1 on https://patchwork.kernel.org/patch/9322553/ - Reviewed-on:

[PATCH v2 0/9] rockchip: add more power domain and devices dts for rk3399

Hi all, Please allow me to integrate these patches. They are missing or losing for upstream, then there are some patches are always depending on them. The following patches are releated to PD. git log --oneline 827198c arm64: dts: rockchip: add the usb3 pd for rk3399 95e95b4 arm64: dts:

[PATCH v2 4/9] arm64: dts: rockchip: add eDP device node for rk3399

From: Yakir Yang Add rk3399 eDP device node, and connect to VOP device node with remote endpoint. Signed-off-by: Yakir Yang Signed-off-by: Caesar Wang (Caesar rebase the lastest and solve the conflict) --- Changes in v2: - Yakir

[PATCH v2 0/9] rockchip: add more power domain and devices dts for rk3399

Hi all, Please allow me to integrate these patches. They are missing or losing for upstream, then there are some patches are always depending on them. The following patches are releated to PD. git log --oneline 827198c arm64: dts: rockchip: add the usb3 pd for rk3399 95e95b4 arm64: dts:

[PATCH v2 4/9] arm64: dts: rockchip: add eDP device node for rk3399

From: Yakir Yang Add rk3399 eDP device node, and connect to VOP device node with remote endpoint. Signed-off-by: Yakir Yang Signed-off-by: Caesar Wang (Caesar rebase the lastest and solve the conflict) --- Changes in v2: - Yakir posted the original patch on -

[PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399

From: Ziyuan Xu Control power domain for eMMC via genpd to reduce power consumption. Signed-off-by: Elaine Zhang Signed-off-by: Ziyuan Xu Signed-off-by: Caesar Wang --- Changes in v2: - Reviewed-on:

[PATCH V2 0/2] pinctrl: tegra: Add support for IO pad control

NVIDIA Tegra124 and later SoCs support the multi-voltage level and low power state of some of its IO pads. The IO pads can work in the voltage of the 1.8V and 3.3V of IO power rail sources. When IO interface are not used then IO pads can be configure in low power state to reduce the power from

[PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399

From: Ziyuan Xu Control power domain for eMMC via genpd to reduce power consumption. Signed-off-by: Elaine Zhang Signed-off-by: Ziyuan Xu Signed-off-by: Caesar Wang --- Changes in v2: - Reviewed-on: https://chromium-review.googlesource.com/376558 - Verified on ChromeOS kernel4.4

[PATCH V2 0/2] pinctrl: tegra: Add support for IO pad control

NVIDIA Tegra124 and later SoCs support the multi-voltage level and low power state of some of its IO pads. The IO pads can work in the voltage of the 1.8V and 3.3V of IO power rail sources. When IO interface are not used then IO pads can be configure in low power state to reduce the power from

Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

On Tue, Nov 08, 2016 at 09:06:31PM +0100, Thomas Gleixner wrote: > The upcoming ring3 mwait stuff can add its magic to tweak that MSR into > this function. > > Stick the call at the end of init_scattered_cpuid_features() for now. I > still need to figure out a proper place for it. So Thomas and

Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

On Tue, Nov 08, 2016 at 09:06:31PM +0100, Thomas Gleixner wrote: > The upcoming ring3 mwait stuff can add its magic to tweak that MSR into > this function. > > Stick the call at the end of init_scattered_cpuid_features() for now. I > still need to figure out a proper place for it. So Thomas and

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-09 08:09 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@pobox.com] .. >> The MTU/MRU on this link is the standard 1500 bytes, so a pkt_len of 2045 >> isn't >> valid here. >> And the rx_desc values look an awful lot like the rx_data values that follow >> it. >> >> There's definitely

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-09 08:09 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@pobox.com] .. >> The MTU/MRU on this link is the standard 1500 bytes, so a pkt_len of 2045 >> isn't >> valid here. >> And the rx_desc values look an awful lot like the rx_data values that follow >> it. >> >> There's definitely

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > > > > Hello, Bruce. > > > > On Tue, Nov 08, 2016 at 04:39:11PM -0500, J. Bruce Fields wrote: > > > > > > Apologies, just cleaning out old mail and finding some I should have

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > > > > Hello, Bruce. > > > > On Tue, Nov 08, 2016 at 04:39:11PM -0500, J. Bruce Fields wrote: > > > > > > Apologies, just cleaning out old mail and finding some I should have

Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode

On 2016.11.09 at 10:10 -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 08, 2016 at 04:10:23PM +0100, Markus Trippelsdorf escreveu: > > On 2016.11.09 at 00:05 +0900, Namhyung Kim wrote: > > > On Tue, Nov 8, 2016 at 10:43 PM, Markus Trippelsdorf > > > wrote: > > > > On

Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode

On 2016.11.09 at 10:10 -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 08, 2016 at 04:10:23PM +0100, Markus Trippelsdorf escreveu: > > On 2016.11.09 at 00:05 +0900, Namhyung Kim wrote: > > > On Tue, Nov 8, 2016 at 10:43 PM, Markus Trippelsdorf > > > wrote: > > > > On 2016.11.08 at 22:08

Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c

Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu: > From: Andi Kleen > > Since the unprivileged sched switch event was added in perf, > PT doesn't need need perf_event_paranoid=-1 anymore for > per cpu decoding. So remove the obsolete paragraph in > the

Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c

Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu: > From: Andi Kleen > > Since the unprivileged sched switch event was added in perf, > PT doesn't need need perf_event_paranoid=-1 anymore for > per cpu decoding. So remove the obsolete paragraph in > the documentation. Thanks for

Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode

On 2016.11.09 at 10:11 -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 08, 2016 at 02:21:17PM +0100, Markus Trippelsdorf escreveu: > > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote: > > > Hello, > > > > > > This patches fix problems in hierarchy output Markus reported some > > > time ago.

Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode

On 2016.11.09 at 10:11 -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 08, 2016 at 02:21:17PM +0100, Markus Trippelsdorf escreveu: > > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote: > > > Hello, > > > > > > This patches fix problems in hierarchy output Markus reported some > > > time ago.

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: >> Well, had to drop it again since it didn't compile: >> >> >> CC [M] drivers/gpu/drm/drm_blend.o >> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’: >>

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: >> Well, had to drop it again since it didn't compile: >> >> >> CC [M] drivers/gpu/drm/drm_blend.o >> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’: >> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

On 11/08/2016 10:18 PM, Robert Jarzmik wrote: [...] >>> +/** >>> + * struct ac97_controller - The AC97 controller of the AC-Link >>> + * @ops: the AC97 operations. >>> + * @controllers: linked list of all existing controllers. >>> + * @dev: the device providing the AC97

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

On 11/08/2016 10:18 PM, Robert Jarzmik wrote: [...] >>> +/** >>> + * struct ac97_controller - The AC97 controller of the AC-Link >>> + * @ops: the AC97 operations. >>> + * @controllers: linked list of all existing controllers. >>> + * @dev: the device providing the AC97

Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

On Tue, Nov 08, 2016 at 10:39:55AM -0800, Kyle Huey wrote: > Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. > When enabled, the processor will fault on attempts to execute the CPUID > instruction with CPL>0. Exposing this feature to userspace will allow a > ptracer to

Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode

Em Tue, Nov 08, 2016 at 02:21:17PM +0100, Markus Trippelsdorf escreveu: > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote: > > Hello, > > > > This patches fix problems in hierarchy output Markus reported some > > time ago. The code is available on the 'perf/hierarchy-fix-v1' branch > > in my

Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode

Em Tue, Nov 08, 2016 at 02:21:17PM +0100, Markus Trippelsdorf escreveu: > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote: > > Hello, > > > > This patches fix problems in hierarchy output Markus reported some > > time ago. The code is available on the 'perf/hierarchy-fix-v1' branch > > in my

Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

On Tue, Nov 08, 2016 at 10:39:55AM -0800, Kyle Huey wrote: > Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. > When enabled, the processor will fault on attempts to execute the CPUID > instruction with CPL>0. Exposing this feature to userspace will allow a > ptracer to

Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode

Em Tue, Nov 08, 2016 at 04:10:23PM +0100, Markus Trippelsdorf escreveu: > On 2016.11.09 at 00:05 +0900, Namhyung Kim wrote: > > On Tue, Nov 8, 2016 at 10:43 PM, Markus Trippelsdorf > > wrote: > > > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote: > > >> This patches fix

Re: [PATCH 0/4] perf tools: Assorted fixes for hierarchy mode

Em Tue, Nov 08, 2016 at 04:10:23PM +0100, Markus Trippelsdorf escreveu: > On 2016.11.09 at 00:05 +0900, Namhyung Kim wrote: > > On Tue, Nov 8, 2016 at 10:43 PM, Markus Trippelsdorf > > wrote: > > > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote: > > >> This patches fix problems in hierarchy

RE: [PATCH net] r8152: Fix broken RX checksums.

Mark Lord [mailto:ml...@pobox.com] > Sent: Friday, November 04, 2016 9:50 PM [...] > Yeah, the device or driver is definitely getting confused with rx_desc > structures. > I added code to check for unlikely rx_desc values, and it found this for > starters: > > rx_desc: 00480801 00480401

RE: [PATCH net] r8152: Fix broken RX checksums.

Mark Lord [mailto:ml...@pobox.com] > Sent: Friday, November 04, 2016 9:50 PM [...] > Yeah, the device or driver is definitely getting confused with rx_desc > structures. > I added code to check for unlikely rx_desc values, and it found this for > starters: > > rx_desc: 00480801 00480401

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

On 11/04/2016 05:49 PM, Måns Rullgård wrote: >>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers >>> will apply the delay. >>> >>> I think a better way of dealing with this is that both, PHY and MAC >>> drivers exchange information so that the delay is applied only once. >>

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

On 11/04/2016 05:49 PM, Måns Rullgård wrote: >>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers >>> will apply the delay. >>> >>> I think a better way of dealing with this is that both, PHY and MAC >>> drivers exchange information so that the delay is applied only once. >>

Re: [PATCH 0/4] cputime: some optimizations and cleanups

2016-10-31 12:36 GMT+00:00 Stanislaw Gruszka : > Patches remove accounting of utimescaled/stimescaled on architectures > that do not provide those values (scaled cputimes are equal to normal > cputimes) what is every architecture except powerpc and s390. > > Patches do not

Re: [PATCH 0/4] cputime: some optimizations and cleanups

2016-10-31 12:36 GMT+00:00 Stanislaw Gruszka : > Patches remove accounting of utimescaled/stimescaled on architectures > that do not provide those values (scaled cputimes are equal to normal > cputimes) what is every architecture except powerpc and s390. > > Patches do not change user visible

[PATCH 1/2] skd: fix msix error handling

As reported by gcc -Wmaybe-uninitialized, the cleanup path for skd_acquire_msix tries to free the already allocated msi-x vectors in reverse order, but the index variable may not have been used yet: drivers/block/skd_main.c: In function ‘skd_acquire_irq’: drivers/block/skd_main.c:3890:8: error:

[PATCH 2/2] skd: fix function prototype

Building with W=1 shows a harmless warning for the skd driver: drivers/block/skd_main.c:2959:1: error: ‘static’ is not at beginning of declaration [-Werror=old-style-declaration] This changes the prototype to the expected formatting. Signed-off-by: Arnd Bergmann ---

[PATCH 1/2] skd: fix msix error handling

As reported by gcc -Wmaybe-uninitialized, the cleanup path for skd_acquire_msix tries to free the already allocated msi-x vectors in reverse order, but the index variable may not have been used yet: drivers/block/skd_main.c: In function ‘skd_acquire_irq’: drivers/block/skd_main.c:3890:8: error:

[PATCH 2/2] skd: fix function prototype

Building with W=1 shows a harmless warning for the skd driver: drivers/block/skd_main.c:2959:1: error: ‘static’ is not at beginning of declaration [-Werror=old-style-declaration] This changes the prototype to the expected formatting. Signed-off-by: Arnd Bergmann --- drivers/block/skd_main.c

Re: [lkp] [x86/copy_user] adb402cd14: will-it-scale.per_process_ops -12.7% regression

On Mon, Nov 07, 2016 at 10:50:38AM +0800, kernel test robot wrote: > > Greeting, > > FYI, we noticed a -12.7% regression of will-it-scale.per_process_ops due to > commit: > > > commit adb402cd1461eef6e1a21db4532a3b9e6a6be853 ("x86/copy_user: Unify the > code by removing the 64-bit asm

[PATCH v2 2/4] printk/kdb: Handle more message headers

The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for printing continuation lines") allows to define more message headers for a single message. The motivation is that continuous lines might get mixed. Therefore it make sense to define the right log level for every piece of a cont

[PATCH v2 4/4] printk/sound: Handle more message headers

The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for printing continuation lines") allows to define more message headers for a single message. The motivation is that continuous lines might get mixed. Therefore it make sense to define the right log level for every piece of a cont

[PATCH v2 3/4] printk/btrfs: Handle more message headers

The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for printing continuation lines") allows to define more message headers for a single message. The motivation is that continuous lines might get mixed. Therefore it make sense to define the right log level for every piece of a cont

Re: [lkp] [x86/copy_user] adb402cd14: will-it-scale.per_process_ops -12.7% regression

On Mon, Nov 07, 2016 at 10:50:38AM +0800, kernel test robot wrote: > > Greeting, > > FYI, we noticed a -12.7% regression of will-it-scale.per_process_ops due to > commit: > > > commit adb402cd1461eef6e1a21db4532a3b9e6a6be853 ("x86/copy_user: Unify the > code by removing the 64-bit asm

[PATCH v2 2/4] printk/kdb: Handle more message headers

The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for printing continuation lines") allows to define more message headers for a single message. The motivation is that continuous lines might get mixed. Therefore it make sense to define the right log level for every piece of a cont

[PATCH v2 4/4] printk/sound: Handle more message headers

The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for printing continuation lines") allows to define more message headers for a single message. The motivation is that continuous lines might get mixed. Therefore it make sense to define the right log level for every piece of a cont

[PATCH v2 3/4] printk/btrfs: Handle more message headers

The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for printing continuation lines") allows to define more message headers for a single message. The motivation is that continuous lines might get mixed. Therefore it make sense to define the right log level for every piece of a cont

[PATCH v2 1/4] printk/NMI: Handle continuous lines and missing newline

The commit 4bcc595ccd80decb4245 ("printk: reinstate KERN_CONT for printing continuation lines") added back KERN_CONT message header. As a result it might appear in the middle of the line when the parts are squashed via the temporary NMI buffer. A reasonable solution seems to be to split the text

[PATCH v2 0/4] printk: Fixes and hardening related to KERN_CONT

The first patch fixes a messed output of continuous lines when printing backtraces for all CPUs via NMI. The other patches fix problems that I noticed when working on the first patch. I have incorporated the feedback and did much more testing. Åll patches have changed so I did not add the taken

[PATCH v2 1/4] printk/NMI: Handle continuous lines and missing newline

The commit 4bcc595ccd80decb4245 ("printk: reinstate KERN_CONT for printing continuation lines") added back KERN_CONT message header. As a result it might appear in the middle of the line when the parts are squashed via the temporary NMI buffer. A reasonable solution seems to be to split the text

[PATCH v2 0/4] printk: Fixes and hardening related to KERN_CONT

The first patch fixes a messed output of continuous lines when printing backtraces for all CPUs via NMI. The other patches fix problems that I noticed when working on the first patch. I have incorporated the feedback and did much more testing. Åll patches have changed so I did not add the taken

<    8   9   10   11   12   13   14   15   16   17   >