[PATCH v11 04/22] vfio: Common function to increment container_users

This change rearrange functions to have common function to increment container_users Signed-off-by: Kirti Wankhede Signed-off-by: Neo Jia Change-Id: I8bdeb352bc8439b107ffd519480fd4dc238677f2 --- drivers/vfio/vfio.c | 34 +- 1 file changed, 21 insertions(+), 13

[PATCH v11 01/22] vfio: Mediated device Core driver

Design for Mediated Device Driver: Main purpose of this driver is to provide a common interface for mediated device management that can be used by different drivers of different devices. This module provides a generic interface to create the device, add it to mediated bus, add device to IOMMU

Re: [PATCH 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx

On Friday 04 November 2016 11:04 AM, Sekhar Nori wrote: > Hi Kishon, > > On Thursday 03 November 2016 10:20 PM, Kishon Vijay Abraham I wrote: >> >> >> On Wednesday 02 November 2016 06:14 PM, Axel Haslam wrote: >>> There is only one ohci on the da8xx series of chips, >>> so remove the ".0" when

Re: [PATCH 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx

On Friday 04 November 2016 11:04 AM, Sekhar Nori wrote: > Hi Kishon, > > On Thursday 03 November 2016 10:20 PM, Kishon Vijay Abraham I wrote: >> >> >> On Wednesday 02 November 2016 06:14 PM, Axel Haslam wrote: >>> There is only one ohci on the da8xx series of chips, >>> so remove the ".0" when

[RESEND PATCH v2] regulator: fixed: Handle optional overcurrent pin

Fixed regulators (ex. TPS2087D) may have a over current pin that is activated on over current. Consumers may be interested to know about over current events to take appropriate actions. Allow the fix regulator to take in an optional gpio pin for over current and send the respective event to the

[RESEND PATCH v2] regulator: fixed: Handle optional overcurrent pin

Fixed regulators (ex. TPS2087D) may have a over current pin that is activated on over current. Consumers may be interested to know about over current events to take appropriate actions. Allow the fix regulator to take in an optional gpio pin for over current and send the respective event to the

Re: Coding Style: Reverse XMAS tree declarations ? (was Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet)

On Fri, Nov 04, 2016 at 10:05:15AM -0700, Randy Dunlap wrote: > On 11/03/16 23:53, Joe Perches wrote: > > On Thu, 2016-11-03 at 15:58 -0400, David Miller wrote: > >> From: Madalin Bucur > >> Date: Wed, 2 Nov 2016 22:17:26 +0200 > >> > >>> This introduces the Freescale Data

Re: Coding Style: Reverse XMAS tree declarations ? (was Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet)

On Fri, Nov 04, 2016 at 10:05:15AM -0700, Randy Dunlap wrote: > On 11/03/16 23:53, Joe Perches wrote: > > On Thu, 2016-11-03 at 15:58 -0400, David Miller wrote: > >> From: Madalin Bucur > >> Date: Wed, 2 Nov 2016 22:17:26 +0200 > >> > >>> This introduces the Freescale Data Path Acceleration

Re: [PATCH] [v9]Input: evdev: fix bug of dropping valid packet after syn_dropped event

Hello Mr. Torokhov, As you can see that this patch is pending for a long time, I request you to please review it at the earliest possible. Thanks, Aniroop Mathur On Thu, Oct 13, 2016 at 12:05 AM, Aniroop Mathur wrote: > Hello Mr. Torokhov, > > Hope you are doing

Re: [PATCH] [v9]Input: evdev: fix bug of dropping valid packet after syn_dropped event

Hello Mr. Torokhov, As you can see that this patch is pending for a long time, I request you to please review it at the earliest possible. Thanks, Aniroop Mathur On Thu, Oct 13, 2016 at 12:05 AM, Aniroop Mathur wrote: > Hello Mr. Torokhov, > > Hope you are doing great! > > Could you please

Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory

On 2016-11-04 16:42:33 [-0400], Charles (Chas) Williams wrote: > This comes from here: > > unsigned int apicid = apic->cpu_present_to_apicid(cpu); > > if (apicid == BAD_APICID || !apic->apic_id_valid(apicid)) > continue; >

Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory

On 2016-11-04 16:42:33 [-0400], Charles (Chas) Williams wrote: > This comes from here: > > unsigned int apicid = apic->cpu_present_to_apicid(cpu); > > if (apicid == BAD_APICID || !apic->apic_id_valid(apicid)) > continue; >

Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules

Quoting Peter Chen (2016-10-24 18:16:32) > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote: > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05) > > > Hi, > > > > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd > > > wrote: > > > > The ULPI bus can be built as

Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules

Quoting Peter Chen (2016-10-24 18:16:32) > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote: > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05) > > > Hi, > > > > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd > > > wrote: > > > > The ULPI bus can be built as a module, and it will

Re: [PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's

On Tue, Nov 1, 2016 at 9:51 PM, Joshua Clayton wrote: > imx-weim should always set address-cells to 2, > and size_cells to 1. > On imx6, fsl,weim-cs-gpr will always be > > Set these common parameters in the dtsi file, > rather than in a downstream dts. > >

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

Anyone have advice where else I can ask? On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis wrote: > Anyone have suggestions? > > On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis > wrote: >> Hi, >> >> I recently had trouble with loading a 4.9rcX

Re: [PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's

On Tue, Nov 1, 2016 at 9:51 PM, Joshua Clayton wrote: > imx-weim should always set address-cells to 2, > and size_cells to 1. > On imx6, fsl,weim-cs-gpr will always be > > Set these common parameters in the dtsi file, > rather than in a downstream dts. > > Signed-off-by: Joshua Clayton

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

Anyone have advice where else I can ask? On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis wrote: > Anyone have suggestions? > > On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis > wrote: >> Hi, >> >> I recently had trouble with loading a 4.9rcX kernel, which was hanging >> after loading the

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! > > Let me try v4.9-rc2... that works ok (cpus at the high frequency > > during the kernel build). Unfortunately that sends my cpus to 99C > > temperature range (and eventually forces emergency shutdown). > > This we have to debug. Do you see same line like  > " >

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! > > Let me try v4.9-rc2... that works ok (cpus at the high frequency > > during the kernel build). Unfortunately that sends my cpus to 99C > > temperature range (and eventually forces emergency shutdown). > > This we have to debug. Do you see same line like  > " >

Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory

On 11/04/2016 02:03 PM, Sebastian Andrzej Siewior wrote: On 2016-11-04 08:20:37 [-0400], Charles (Chas) Williams wrote: The initial CPU boots and is identified: [0.009018] identify_boot_cpu [0.009174] generic_identify: phys_proc_id is now 0 ... [0.009427] identify_cpu: before c

Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory

On 11/04/2016 02:03 PM, Sebastian Andrzej Siewior wrote: On 2016-11-04 08:20:37 [-0400], Charles (Chas) Williams wrote: The initial CPU boots and is identified: [0.009018] identify_boot_cpu [0.009174] generic_identify: phys_proc_id is now 0 ... [0.009427] identify_cpu: before c

Re: [PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver

Bartosz Golaszewski writes: > Create the driver for the da8xx master peripheral priority > configuration and implement support for writing to the three > Master Priority registers on da850 SoCs. > > Signed-off-by: Bartosz Golaszewski

Re: [PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver

Bartosz Golaszewski writes: > Create the driver for the da8xx master peripheral priority > configuration and implement support for writing to the three > Master Priority registers on da850 SoCs. > > Signed-off-by: Bartosz Golaszewski Reviewed-by: Kevin Hilman

Applied "ASoC: sun4i-codec: Add support for A31 analog microphone inputs" to the asoc tree

The patch ASoC: sun4i-codec: Add support for A31 analog microphone inputs has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: sun4i-codec: Add support for A31 board level audio routing" to the asoc tree

The patch ASoC: sun4i-codec: Add support for A31 board level audio routing has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver

Bartosz Golaszewski writes: > Create a new driver for the da8xx DDR2/mDDR controller and implement > support for writing to the Peripheral Bus Burst Priority Register. > > Signed-off-by: Bartosz Golaszewski Reviewed-by: Kevin Hilman

Applied "ASoC: sun4i-codec: Add support for A31 analog microphone inputs" to the asoc tree

The patch ASoC: sun4i-codec: Add support for A31 analog microphone inputs has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: sun4i-codec: Add support for A31 board level audio routing" to the asoc tree

The patch ASoC: sun4i-codec: Add support for A31 board level audio routing has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver

Bartosz Golaszewski writes: > Create a new driver for the da8xx DDR2/mDDR controller and implement > support for writing to the Peripheral Bus Burst Priority Register. > > Signed-off-by: Bartosz Golaszewski Reviewed-by: Kevin Hilman

Applied "ASoC: sun4i-codec: Add support for A31 Line Out playback" to the asoc tree

The patch ASoC: sun4i-codec: Add support for A31 Line Out playback has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

[GIT PULL] PCI fixes for v4.9

This includes: - Fix for a Qualcomm driver issue that causes a use-before-set crash - Fix for DesignWare iATU unroll support that causes external aborts when enabling the host bridge The following changes since commit 02a1b8f4167eac709d269341f7c3c340984c28a6: PCI: designware-plat:

Applied "ASoC: sun4i-codec: Add support for A31 Line Out playback" to the asoc tree

The patch ASoC: sun4i-codec: Add support for A31 Line Out playback has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

[GIT PULL] PCI fixes for v4.9

This includes: - Fix for a Qualcomm driver issue that causes a use-before-set crash - Fix for DesignWare iATU unroll support that causes external aborts when enabling the host bridge The following changes since commit 02a1b8f4167eac709d269341f7c3c340984c28a6: PCI: designware-plat:

Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query

On Fri, Nov 4, 2016 at 1:29 PM, Pavel Machek wrote: > On Fri 2016-11-04 07:58:55, Tony Lindgren wrote: >> * Pavel Machek [161104 00:10]: >> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote: >> > Do you actually have hardware with more than one bq27xxx? >> >> I can at

Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query

On Fri, Nov 4, 2016 at 1:29 PM, Pavel Machek wrote: > On Fri 2016-11-04 07:58:55, Tony Lindgren wrote: >> * Pavel Machek [161104 00:10]: >> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote: >> > Do you actually have hardware with more than one bq27xxx? >> >> I can at least see the twl4030

Re: [git pull] drm fixes for 4.9-rc4

On Wed, Nov 2, 2016 at 5:31 PM, Dave Airlie wrote: > > There are a set of fixes for an oops we've been seeing around MST > display unplug, Side note: I heard from a couple of people at the KS that said that they had had problems with suspend/resume after plugging in to a 4k

Re: [git pull] drm fixes for 4.9-rc4

On Wed, Nov 2, 2016 at 5:31 PM, Dave Airlie wrote: > > There are a set of fixes for an oops we've been seeing around MST > display unplug, Side note: I heard from a couple of people at the KS that said that they had had problems with suspend/resume after plugging in to a 4k display (but _only_ a

Re: [PATCH] i2c: make busses/i2c-pxa-pci.c explicitly non-modular

On 2016-11-04 20:47:49 [+0100], Wolfram Sang wrote: > Looks OK to me, still I'd like an ack from Sebastian for this patch. > Acked-by: Sebastian Andrzej Siewior Sebastian

Re: [PATCH] i2c: make busses/i2c-pxa-pci.c explicitly non-modular

On 2016-11-04 20:47:49 [+0100], Wolfram Sang wrote: > Looks OK to me, still I'd like an ack from Sebastian for this patch. > Acked-by: Sebastian Andrzej Siewior Sebastian

Re: [PATCH 10/10] clk: ti: make clk-dra7-atl explicitly non-modular

On 07/04, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > arch/arm/mach-omap2/Kconfig:config SOC_DRA7XX > arch/arm/mach-omap2/Kconfig:bool "TI DRA7XX" > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the

Re: [PATCH 10/10] clk: ti: make clk-dra7-atl explicitly non-modular

On 07/04, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > arch/arm/mach-omap2/Kconfig:config SOC_DRA7XX > arch/arm/mach-omap2/Kconfig:bool "TI DRA7XX" > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the

Re: [PATCH v8 7/7] KVM: x86: virtualize cpuid faulting

On Mon, Oct 31, 2016 at 6:37 PM, Kyle Huey wrote: > Hardware support for faulting on the cpuid instruction is not required to > emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant > MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a >

Re: [PATCH v8 7/7] KVM: x86: virtualize cpuid faulting

On Mon, Oct 31, 2016 at 6:37 PM, Kyle Huey wrote: > Hardware support for faulting on the cpuid instruction is not required to > emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant > MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a > cpuid-induced VM exit

Re: [PATCH 14/17] ASoC: add simple-graph-card document

On Mon, Oct 31, 2016 at 01:19:58AM +, Kuninori Morimoto wrote: > +This Simple-Graph-Card should be located as CPU driver's port[s]. > +And then, CPU driver need to probe it by itself. This document really needs quite a bit of fleshing out but I'm not sure that should be a blocker for the

Re: [PATCH 14/17] ASoC: add simple-graph-card document

On Mon, Oct 31, 2016 at 01:19:58AM +, Kuninori Morimoto wrote: > +This Simple-Graph-Card should be located as CPU driver's port[s]. > +And then, CPU driver need to probe it by itself. This document really needs quite a bit of fleshing out but I'm not sure that should be a blocker for the

Re: [PATCH 09/10] clk: tegra: make clk-tegra124-dfll-fcpu explicitly non-modular

On 07/04, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > arch/arm/mach-tegra/Kconfig:config ARCH_TEGRA_124_SOC > arch/arm/mach-tegra/Kconfig:bool "Enable support for Tegra124 family" > > ...meaning that it currently is not being built as a module

Re: [PATCH 09/10] clk: tegra: make clk-tegra124-dfll-fcpu explicitly non-modular

On 07/04, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > arch/arm/mach-tegra/Kconfig:config ARCH_TEGRA_124_SOC > arch/arm/mach-tegra/Kconfig:bool "Enable support for Tegra124 family" > > ...meaning that it currently is not being built as a module

Re: [PATCH 03/10] clk: mvebu: make cp110-system-controller explicitly non-modular

On 07/04, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/clk/mvebu/Kconfig:config ARMADA_CP110_SYSCON > drivers/clk/mvebu/Kconfig: bool > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the modular

Re: [PATCH 03/10] clk: mvebu: make cp110-system-controller explicitly non-modular

On 07/04, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/clk/mvebu/Kconfig:config ARMADA_CP110_SYSCON > drivers/clk/mvebu/Kconfig: bool > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the modular

Re: [PATCH 04/10] clk: mvebu: make ap806-system-controller explicitly non-modular

On 07/04, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/clk/mvebu/Kconfig:config ARMADA_AP806_SYSCON > drivers/clk/mvebu/Kconfig: bool > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the modular

Re: [PATCH 04/10] clk: mvebu: make ap806-system-controller explicitly non-modular

On 07/04, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/clk/mvebu/Kconfig:config ARMADA_AP806_SYSCON > drivers/clk/mvebu/Kconfig: bool > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the modular

Re: [RFC v2 5/7] powerpc: Rename context.vdso_base to context.vdso

[fixing akpm's email address] On Fri, Nov 04, 2016 at 03:58:22PM +1100, Michael Ellerman wrote: > Christopher Covington writes: > > > Checkpoint/Restore In Userspace (CRIU) needs to be able to unmap and remap > > the VDSO to successfully checkpoint and restore applications

Re: [RFC v2 5/7] powerpc: Rename context.vdso_base to context.vdso

[fixing akpm's email address] On Fri, Nov 04, 2016 at 03:58:22PM +1100, Michael Ellerman wrote: > Christopher Covington writes: > > > Checkpoint/Restore In Userspace (CRIU) needs to be able to unmap and remap > > the VDSO to successfully checkpoint and restore applications in the face of > >

Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query

On Fri 2016-11-04 07:58:55, Tony Lindgren wrote: > * Pavel Machek [161104 00:10]: > > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote: > > Do you actually have hardware with more than one bq27xxx? > > I can at least see the twl4030 battery/charger features > being used together

Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query

On Fri 2016-11-04 07:58:55, Tony Lindgren wrote: > * Pavel Machek [161104 00:10]: > > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote: > > Do you actually have hardware with more than one bq27xxx? > > I can at least see the twl4030 battery/charger features > being used together with some bq

Re: [PATCH v4 3/4] usb: musb: Add a quirk flag to skip the phy set mode

Hello. On 11/04/2016 07:43 PM, Alexandre Bailon wrote: During the init, the driver will use the mode to configure the controller mode and the phy mode. PHY -- be consistent please... The PHY of DA8xx has some issues when the phy is forced in host or device. Again. Add way to skip

Re: [PATCH v4 3/4] usb: musb: Add a quirk flag to skip the phy set mode

Hello. On 11/04/2016 07:43 PM, Alexandre Bailon wrote: During the init, the driver will use the mode to configure the controller mode and the phy mode. PHY -- be consistent please... The PHY of DA8xx has some issues when the phy is forced in host or device. Again. Add way to skip

Re: [PATCH-v2] ARC: syscall for userspace cmpxchg assist

On 10/24/2016 09:17 AM, Vineet Gupta wrote: > Older ARC700 cores (ARC750 specifically) lack instructions to implement > atomic r-w-w. This is problematic for userspace libraries such as NPTL > which need atomic primitives. So enable them by providing kernel assist. > This is costly but really the

Re: [PATCH v3] clk: pxa: transfer CPU clock setting from pxa2xx-cpufreq

On 11/02, Robert Jarzmik wrote: > This is the initial stage to transfer the pxa25x and pxa27x CPU clocks > handling from cpufreq to the clock API. More precisely, the clocks > transferred are : > - cpll : core pll, known also as the CPU core turbo frequency > - core : core, known also as the CPU

Re: [PATCH-v2] ARC: syscall for userspace cmpxchg assist

On 10/24/2016 09:17 AM, Vineet Gupta wrote: > Older ARC700 cores (ARC750 specifically) lack instructions to implement > atomic r-w-w. This is problematic for userspace libraries such as NPTL > which need atomic primitives. So enable them by providing kernel assist. > This is costly but really the

Re: [PATCH v3] clk: pxa: transfer CPU clock setting from pxa2xx-cpufreq

On 11/02, Robert Jarzmik wrote: > This is the initial stage to transfer the pxa25x and pxa27x CPU clocks > handling from cpufreq to the clock API. More precisely, the clocks > transferred are : > - cpll : core pll, known also as the CPU core turbo frequency > - core : core, known also as the CPU

Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks

On 11/04, Sricharan wrote: > Hi, > > > >A better design would be to check if the associated GDSC is in hw > >control mode and then skip the checks because the clocks are no > >longer under the control of the registers. I presume we only > >enable the clocks here to turn on parent clocks which

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

On 16-11-04 09:50 AM, Mark Lord wrote: > 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 00480001 0048fc00 0048f800 0048f400 pkt_len=2045 >

Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks

On 11/04, Sricharan wrote: > Hi, > > > >A better design would be to check if the associated GDSC is in hw > >control mode and then skip the checks because the clocks are no > >longer under the control of the registers. I presume we only > >enable the clocks here to turn on parent clocks which

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

On 16-11-04 09:50 AM, Mark Lord wrote: > 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 00480001 0048fc00 0048f800 0048f400 pkt_len=2045 >

Re: [PATCH 05/17] ASoC: soc-core: snd_soc_get_dai_name() become non static

On Mon, Oct 31, 2016 at 01:17:09AM +, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > snd_soc_get_dai_name() is used from snd_soc_of_get_dai_name(), > and it is assuming that DT is using "sound-dai" / "#sound-dai-cells". > But graph base DT is using

Re: [PATCH 05/17] ASoC: soc-core: snd_soc_get_dai_name() become non static

On Mon, Oct 31, 2016 at 01:17:09AM +, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > snd_soc_get_dai_name() is used from snd_soc_of_get_dai_name(), > and it is assuming that DT is using "sound-dai" / "#sound-dai-cells". > But graph base DT is using "remote-endpoint". This patch makes

Re: Coding Style: Reverse XMAS tree declarations ?

On 04.11.2016 18:44, Joe Perches wrote: > On Fri, 2016-11-04 at 11:07 -0400, David Miller wrote: >> From: Lino Sanfilippo >> > On 04.11.2016 07:53, Joe Perches wrote: >> >> CHECK:REVERSE_XMAS_TREE: Prefer ordering declarations longest to >> >> shortest >> >> #446: FILE:

Re: Coding Style: Reverse XMAS tree declarations ?

On 04.11.2016 18:44, Joe Perches wrote: > On Fri, 2016-11-04 at 11:07 -0400, David Miller wrote: >> From: Lino Sanfilippo >> > On 04.11.2016 07:53, Joe Perches wrote: >> >> CHECK:REVERSE_XMAS_TREE: Prefer ordering declarations longest to >> >> shortest >> >> #446: FILE:

Re: [PATCH 01/14] pinctrl-sx150x: Rely on of_modalias_node for OF matching

On Fri, Nov 4, 2016 at 5:28 AM, Linus Walleij wrote: > On Tue, Nov 1, 2016 at 4:57 PM, Andrey Smirnov > wrote: > >> None of the OF match table entries contain any compatiblity strings that >> could not be matched against using i2c_device_id

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

On 11/02, Geert Uytterhoeven wrote: > On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd wrote: > > > > Would the pull requests for clk also have dts changes at the base > > of the tree? Perhaps clk side can just ack the clk patches and > > Yes they would: this is moving

Re: [PATCH 01/14] pinctrl-sx150x: Rely on of_modalias_node for OF matching

On Fri, Nov 4, 2016 at 5:28 AM, Linus Walleij wrote: > On Tue, Nov 1, 2016 at 4:57 PM, Andrey Smirnov > wrote: > >> None of the OF match table entries contain any compatiblity strings that >> could not be matched against using i2c_device_id table above and >> of_modalias_node. Besides that

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

On 11/02, Geert Uytterhoeven wrote: > On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd wrote: > > > > Would the pull requests for clk also have dts changes at the base > > of the tree? Perhaps clk side can just ack the clk patches and > > Yes they would: this is moving functionality from platform

Re: [PATCH] i2c: make busses/i2c-pxa-pci.c explicitly non-modular

On Mon, Oct 31, 2016 at 01:59:47PM -0400, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/i2c/busses/Kconfig:config I2C_PXA_PCI > drivers/i2c/busses/Kconfig: def_bool I2C_PXA && X86_32 && PCI && OF > > ...meaning that it currently is not

Re: [PATCH] i2c: make busses/i2c-pxa-pci.c explicitly non-modular

On Mon, Oct 31, 2016 at 01:59:47PM -0400, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/i2c/busses/Kconfig:config I2C_PXA_PCI > drivers/i2c/busses/Kconfig: def_bool I2C_PXA && X86_32 && PCI && OF > > ...meaning that it currently is not

Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"

On Fri, 4 Nov 2016 13:11:35 +0100 Hans de Goede wrote: > This reverts commit 05fd007e4629 ("console: don't prefer first registered > if DT specifies stdout-path"). > > The reverted commit changes existing behavior on which many ARM boards > rely. Many ARM

Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"

On Fri, 4 Nov 2016 13:11:35 +0100 Hans de Goede wrote: > This reverts commit 05fd007e4629 ("console: don't prefer first registered > if DT specifies stdout-path"). > > The reverted commit changes existing behavior on which many ARM boards > rely. Many ARM small-board-computers, like e.g. the

[GIT PULL] nfsd bugfixes for 4.9

Please pull nfsd bugfixes from git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.9-1 --b. Fixes for some recent regressions including fallout from the vmalloc'd stack change (after which we can no longer encrypt stuff on the

[GIT PULL] nfsd bugfixes for 4.9

Please pull nfsd bugfixes from git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.9-1 --b. Fixes for some recent regressions including fallout from the vmalloc'd stack change (after which we can no longer encrypt stuff on the

RE: [PATCH] MIPS: VDSO: Always select -msoft-float

On Fri, 4 Nov 2016, Matthew Fortune wrote: > > This code is executed in the user mode so while floating-point code may > > not be needed there, not at least right now, there's actually nothing > > which should stop us from from adding some should such a need arise. > > Indeed. For now though

RE: [PATCH] MIPS: VDSO: Always select -msoft-float

On Fri, 4 Nov 2016, Matthew Fortune wrote: > > This code is executed in the user mode so while floating-point code may > > not be needed there, not at least right now, there's actually nothing > > which should stop us from from adding some should such a need arise. > > Indeed. For now though

Re: [PATCH v4 3/4] usb: musb: Add a quirk flag to skip the phy set mode

On 11/04/2016 11:43 AM, Alexandre Bailon wrote: During the init, the driver will use the mode to configure the controller mode and the phy mode. The PHY of DA8xx has some issues when the phy is forced in host or device. Add way to skip the set mode and let the da8xx glue manage the phy mode.

Re: [PATCH v4 3/4] usb: musb: Add a quirk flag to skip the phy set mode

On 11/04/2016 11:43 AM, Alexandre Bailon wrote: During the init, the driver will use the mode to configure the controller mode and the phy mode. The PHY of DA8xx has some issues when the phy is forced in host or device. Add way to skip the set mode and let the da8xx glue manage the phy mode.

Re: [PATCH V3 0/6] ARM64: Uprobe support added

On Fri, Nov 04, 2016 at 11:49:51AM -0600, Catalin Marinas wrote: > On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote: > > Pratyush Anand (6): > > arm64: kprobe: protect/rename few definitions to be reused by uprobe > > arm64: kgdb_step_brk_fn: ignore other's exception > > arm64:

Re: [PATCH V3 0/6] ARM64: Uprobe support added

On Fri, Nov 04, 2016 at 11:49:51AM -0600, Catalin Marinas wrote: > On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote: > > Pratyush Anand (6): > > arm64: kprobe: protect/rename few definitions to be reused by uprobe > > arm64: kgdb_step_brk_fn: ignore other's exception > > arm64:

Strange stacktrace with the kernel 4.9-rc3

Hi I've got these two stacktraces with the kernel 4.9-rc3. The strange thing is that the kernel doesn't say what kind of problem happened - just a register dump and stack trace. It happened on virtual machine guest running in qemu-kvm. Mikulas [ 166.917189] CPU: 0 PID: 0 Comm: swapper/0

Strange stacktrace with the kernel 4.9-rc3

Hi I've got these two stacktraces with the kernel 4.9-rc3. The strange thing is that the kernel doesn't say what kind of problem happened - just a register dump and stack trace. It happened on virtual machine guest running in qemu-kvm. Mikulas [ 166.917189] CPU: 0 PID: 0 Comm: swapper/0

-fno-PIE, take #3

Debian gcc's is nowdays compiled with --enable-default-pie which means it does -fPIE by default. This breaks atleast x86-64 compiles. This is the third attempt to fix it, this time by using runtime detection of the -fno-PIE compiler switch (it was introduced in gcc 3.4, min required gcc is

-fno-PIE, take #3

Debian gcc's is nowdays compiled with --enable-default-pie which means it does -fPIE by default. This breaks atleast x86-64 compiles. This is the third attempt to fix it, this time by using runtime detection of the -fno-PIE compiler switch (it was introduced in gcc 3.4, min required gcc is

Re: [PATCH net-next v2 00/11] net: dsa: mv88e6xxx: refine port operations

From: Vivien Didelot Date: Fri, 4 Nov 2016 03:23:25 +0100 > The Marvell chips have one internal SMI device per port, containing a > set of registers used to configure a port's link, STP state, default > VLAN or addresses database, etc. > > This patchset

Re: [PATCH net-next v2 00/11] net: dsa: mv88e6xxx: refine port operations

From: Vivien Didelot Date: Fri, 4 Nov 2016 03:23:25 +0100 > The Marvell chips have one internal SMI device per port, containing a > set of registers used to configure a port's link, STP state, default > VLAN or addresses database, etc. > > This patchset creates port files to implement the port

[PATCH 1/3] kbuild: add -fno-PIE

Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with: |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Also add to KBUILD_AFLAGS due to: |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY

[PATCH 1/3] kbuild: add -fno-PIE

Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with: |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Also add to KBUILD_AFLAGS due to: |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY

[PATCH 2/3] scripts/has-stack-protector: add -fno-PIE

Adding -no-PIE to the fstack protector check. -no-PIE was introduced before -fstack-protector so there is no need for a runtime check. Without it the build stops: |Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken due to -mcmodel=kernel +

[PATCH 3/3] x86/kexec: add -fno-PIE

If the gcc is configured to do -fPIE by default then the build aborts later with: | Unsupported relocation type: unknown type rel type name (29) Tagging it stable so it is possible to compile recent stable kernels as well. Cc: sta...@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior

[PATCH 2/3] scripts/has-stack-protector: add -fno-PIE

Adding -no-PIE to the fstack protector check. -no-PIE was introduced before -fstack-protector so there is no need for a runtime check. Without it the build stops: |Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken due to -mcmodel=kernel +

[PATCH 3/3] x86/kexec: add -fno-PIE

If the gcc is configured to do -fPIE by default then the build aborts later with: | Unsupported relocation type: unknown type rel type name (29) Tagging it stable so it is possible to compile recent stable kernels as well. Cc: sta...@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior ---

RE: [PATCH 4/9] bus: fsl-mc: dpio: add frame descriptor and scatter/gather APIs

> -Original Message- > From: Stuart Yoder > Sent: Friday, November 04, 2016 4:32 PM > To: Ruxandra Ioana Radulescu ; > gre...@linuxfoundation.org > Cc: German Rivera ; de...@driverdev.osuosl.org; > linux-kernel@vger.kernel.org;

RE: [PATCH 4/9] bus: fsl-mc: dpio: add frame descriptor and scatter/gather APIs

> -Original Message- > From: Stuart Yoder > Sent: Friday, November 04, 2016 4:32 PM > To: Ruxandra Ioana Radulescu ; > gre...@linuxfoundation.org > Cc: German Rivera ; de...@driverdev.osuosl.org; > linux-kernel@vger.kernel.org; ag...@suse.de; a...@arndb.de; Leo Li > ; Roy Pledge >

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