Re: [tip:core/signals] signals/sigaltstack, x86/signals: Unify the x86 sigaltstack check with other architectures

On Tue, May 3, 2016 at 12:49 AM, tip-bot for Stas Sergeev wrote: > Commit-ID: 0b4521e8cf1f582da3045ea460427ac2f741578f > Gitweb: http://git.kernel.org/tip/0b4521e8cf1f582da3045ea460427ac2f741578f > Author: Stas Sergeev > AuthorDate: Thu, 14 Apr 2016

Re: [tip:core/signals] signals/sigaltstack, x86/signals: Unify the x86 sigaltstack check with other architectures

On Tue, May 3, 2016 at 12:49 AM, tip-bot for Stas Sergeev wrote: > Commit-ID: 0b4521e8cf1f582da3045ea460427ac2f741578f > Gitweb: http://git.kernel.org/tip/0b4521e8cf1f582da3045ea460427ac2f741578f > Author: Stas Sergeev > AuthorDate: Thu, 14 Apr 2016 23:20:02 +0300 > Committer: Ingo

Re: [PATCH V5 2/6] of/slimbus: OF helper for SLIMbus

On Wed, Apr 27, 2016 at 05:58:05PM -0600, Sagar Dharia wrote: > OF helper routine scans the SLIMbus DeviceTree, allocates resources, > and creates slim_devices according to the hierarchy. > > Signed-off-by: Sagar Dharia > --- >

Re: [PATCH V5 2/6] of/slimbus: OF helper for SLIMbus

On Wed, Apr 27, 2016 at 05:58:05PM -0600, Sagar Dharia wrote: > OF helper routine scans the SLIMbus DeviceTree, allocates resources, > and creates slim_devices according to the hierarchy. > > Signed-off-by: Sagar Dharia > --- > Documentation/devicetree/bindings/slimbus/bus.txt | 55

Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()

From: Lars Ellenberg Date: Tue, 3 May 2016 12:06:44 +0200 > Whereas using some arbitrary value will be wrong, > and will needlessly break userland. It cannot break userland. A fundamental property of netlink is that all code must silently ignore netlink attributes it

Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()

From: Lars Ellenberg Date: Tue, 3 May 2016 12:06:44 +0200 > Whereas using some arbitrary value will be wrong, > and will needlessly break userland. It cannot break userland. A fundamental property of netlink is that all code must silently ignore netlink attributes it does not understand. This

Re: [PATCH] phy: tegra-xusb: add pinctrl dependency

On Tue, May 03, 2016 at 05:24:51PM +0200, Arnd Bergmann wrote: > The newly added tegra xusb phy driver fails to link when CONFIG_PINCTRL > is disabled, since that also leaves out the legacy probe function: > > ERROR: "tegra_xusb_padctl_legacy_probe" [drivers/phy/tegra/phy-tegra-xusb.ko] >

Re: [PATCH v3 2/2] dt-bindings: imx: ldb: Add ddc-i2c-bus property

On Fri, Apr 29, 2016 at 09:44:12AM +0200, Philipp Zabel wrote: > Am Donnerstag, den 28.04.2016, 16:48 -0500 schrieb Rob Herring: > > On Wed, Apr 27, 2016 at 04:23:34PM -0400, Akshay Bhat wrote: > > > Document the ddc-i2c-bus property used by imx-ldb driver to read EDID > > > information via I2C

Re: [PATCH] phy: tegra-xusb: add pinctrl dependency

On Tue, May 03, 2016 at 05:24:51PM +0200, Arnd Bergmann wrote: > The newly added tegra xusb phy driver fails to link when CONFIG_PINCTRL > is disabled, since that also leaves out the legacy probe function: > > ERROR: "tegra_xusb_padctl_legacy_probe" [drivers/phy/tegra/phy-tegra-xusb.ko] >

Re: [PATCH v3 2/2] dt-bindings: imx: ldb: Add ddc-i2c-bus property

On Fri, Apr 29, 2016 at 09:44:12AM +0200, Philipp Zabel wrote: > Am Donnerstag, den 28.04.2016, 16:48 -0500 schrieb Rob Herring: > > On Wed, Apr 27, 2016 at 04:23:34PM -0400, Akshay Bhat wrote: > > > Document the ddc-i2c-bus property used by imx-ldb driver to read EDID > > > information via I2C

Re: [PATCH V2] pinctrl: tegra: avoid parked_reg and parked_bank

On 05/02/2016 12:47 PM, Laxman Dewangan wrote: NVIDIA's Tegra210 support the park bit to make pinmux configuration enable/disable. If parked bit is 1 then configuration does not apply and if it is 0 then pinmux configuration applies. This is to support to avoid any glitch in pinmux

Re: [PATCH V2] pinctrl: tegra: avoid parked_reg and parked_bank

On 05/02/2016 12:47 PM, Laxman Dewangan wrote: NVIDIA's Tegra210 support the park bit to make pinmux configuration enable/disable. If parked bit is 1 then configuration does not apply and if it is 0 then pinmux configuration applies. This is to support to avoid any glitch in pinmux

Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()

From: Lars Ellenberg Date: Tue, 3 May 2016 12:06:44 +0200 > Please just NOT use an additional "field", > but always use 0 to pad. You can't, it doesn't work. We are adding a new field to every netlink protocol family that has this alignment problem.

Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()

From: Lars Ellenberg Date: Tue, 3 May 2016 12:06:44 +0200 > Please just NOT use an additional "field", > but always use 0 to pad. You can't, it doesn't work. We are adding a new field to every netlink protocol family that has this alignment problem.

[PATCH v8 0/9] ARM: dts: DRA7: Add dt nodes for PWMSS

This patch series adds support for PWM for DRA7. The IP is the same as the one present in AM33XX and AM437XX. However, before doing so remove unnecessary hwmod entries for eCAP, ePWM and eQEP. The following are the biggest changes from v7 to v8: Insure DT unit address matches reg property

Re: [PATCH] media: fix use-after-free in cdev_put() when app exits after driver unbind

On 05/03/2016 05:06 PM, Shuah Khan wrote: > On 05/02/2016 04:16 AM, Lars-Peter Clausen wrote: >> On 04/30/2016 12:37 AM, Shuah Khan wrote: >> [...] >>> diff --git a/include/media/media-devnode.h b/include/media/media-devnode.h >>> index 5bb3b0e..ce9b051 100644 >>> ---

[PATCH v8 0/9] ARM: dts: DRA7: Add dt nodes for PWMSS

This patch series adds support for PWM for DRA7. The IP is the same as the one present in AM33XX and AM437XX. However, before doing so remove unnecessary hwmod entries for eCAP, ePWM and eQEP. The following are the biggest changes from v7 to v8: Insure DT unit address matches reg property

Re: [PATCH] media: fix use-after-free in cdev_put() when app exits after driver unbind

On 05/03/2016 05:06 PM, Shuah Khan wrote: > On 05/02/2016 04:16 AM, Lars-Peter Clausen wrote: >> On 04/30/2016 12:37 AM, Shuah Khan wrote: >> [...] >>> diff --git a/include/media/media-devnode.h b/include/media/media-devnode.h >>> index 5bb3b0e..ce9b051 100644 >>> ---

[PATCH v8 3/9] pwm: pwm-tiehrpwm: Update dt binding document to use generic node name

Now that the node name has been changed from ehrpwm to pwm the document should show this proper usage. Change the unit address in the example from 0 to the proper physical address value that should be used. Also insure that the unit address matches to the reg property. Signed-off-by: Franklin S

[PATCH v8 3/9] pwm: pwm-tiehrpwm: Update dt binding document to use generic node name

Now that the node name has been changed from ehrpwm to pwm the document should show this proper usage. Change the unit address in the example from 0 to the proper physical address value that should be used. Also insure that the unit address matches to the reg property. Signed-off-by: Franklin S

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On 03.05.2016 17:51, Guillaume Nault wrote: > On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote: >> On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote: >>> On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault >>> wrote: On Sun, May 01, 2016 at

Re: Kernel docs: muddying the waters a bit

Daniel Vetter writes: > So sphinx/rst y/n? Jon, is that ok with you from the doc maintainer > pov? I think the right answer for today is to use sphinx to generate docs From inline comments, to encourage outline docs to give it a try but to allow doc writers to use

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On 03.05.2016 17:51, Guillaume Nault wrote: > On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote: >> On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote: >>> On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault >>> wrote: On Sun, May 01, 2016 at 09:38:57PM +0800, Wang

Re: Kernel docs: muddying the waters a bit

Daniel Vetter writes: > So sphinx/rst y/n? Jon, is that ok with you from the doc maintainer > pov? I think the right answer for today is to use sphinx to generate docs From inline comments, to encourage outline docs to give it a try but to allow doc writers to use whatever works for them. That

Re: [RFC PATCH v1 15/18] x86: Enable memory encryption on the APs

On 05/01/2016 05:10 PM, Huang, Kai wrote: > > > On 4/27/2016 10:58 AM, Tom Lendacky wrote: >> Add support to set the memory encryption enable flag on the APs during >> realmode initialization. When an AP is started it checks this flag, and >> if set, enables memory encryption on its core. >> >>

Re: [PATCH V5 0/4] gpio: tegra: Cleanups and support for debounce

On 05/02/2016 01:06 PM, Laxman Dewangan wrote: On Tuesday 03 May 2016 12:14 AM, Stephen Warren wrote: On 05/02/2016 11:58 AM, Laxman Dewangan wrote: Toggling OE bit is something emulating the open drain here. From the perspective of the external HW that's attached to the GPIO, I believe

Re: [patch] ASoC: hdac_hdmi: Potential NULL deref in hdac_hdmi_get_spk_alloc()

On Tue, May 03, 2016 at 03:26:39PM +0530, Vinod Koul wrote: > On Tue, May 03, 2016 at 10:42:58AM +0300, Dan Carpenter wrote: > > We intended || here instead of &&. The original code potentially leads > > to a NULL dereference. > > This looks good to me, I will test this and get back Acked-by:

[PATCH v8 2/9] ARM: dts: am437x: Add missing compatibles to PWM binding documents

There are several SOC specific compatibles for ECAP, EHRPWM and PWMMS that are in use but aren't properly documented. Therefore, fix this by adding the compatibles to the appropriate binding documents. While at it make minor corrections to the binding document. Signed-off-by: Franklin S Cooper

Re: [RFC PATCH] ext4: Don't release mutex for DAX write

On 05/03/2016 04:43 AM, Christoph Hellwig wrote: As explained in another thread I really think we need to get DAX to stop pretending to be direct I/O, which should also take care of the locking. The same issue also exists for ext2 and XFS so it needs to be solved at a higher level. I think

[PATCH v8 4/9] pwm: pwm-tiecap: Update dt binding document to use proper unit address

Replace unit address from 0 to the proper physical address. Also insure that the unit address matches the reg property address. Signed-off-by: Franklin S Cooper Jr --- Documentation/devicetree/bindings/pwm/pwm-tiecap.txt | 8 1 file changed, 4 insertions(+), 4

Re: [RFC PATCH v1 15/18] x86: Enable memory encryption on the APs

On 05/01/2016 05:10 PM, Huang, Kai wrote: > > > On 4/27/2016 10:58 AM, Tom Lendacky wrote: >> Add support to set the memory encryption enable flag on the APs during >> realmode initialization. When an AP is started it checks this flag, and >> if set, enables memory encryption on its core. >> >>

Re: [PATCH V5 0/4] gpio: tegra: Cleanups and support for debounce

On 05/02/2016 01:06 PM, Laxman Dewangan wrote: On Tuesday 03 May 2016 12:14 AM, Stephen Warren wrote: On 05/02/2016 11:58 AM, Laxman Dewangan wrote: Toggling OE bit is something emulating the open drain here. From the perspective of the external HW that's attached to the GPIO, I believe

Re: [patch] ASoC: hdac_hdmi: Potential NULL deref in hdac_hdmi_get_spk_alloc()

On Tue, May 03, 2016 at 03:26:39PM +0530, Vinod Koul wrote: > On Tue, May 03, 2016 at 10:42:58AM +0300, Dan Carpenter wrote: > > We intended || here instead of &&. The original code potentially leads > > to a NULL dereference. > > This looks good to me, I will test this and get back Acked-by:

[PATCH v8 2/9] ARM: dts: am437x: Add missing compatibles to PWM binding documents

There are several SOC specific compatibles for ECAP, EHRPWM and PWMMS that are in use but aren't properly documented. Therefore, fix this by adding the compatibles to the appropriate binding documents. While at it make minor corrections to the binding document. Signed-off-by: Franklin S Cooper

Re: [RFC PATCH] ext4: Don't release mutex for DAX write

On 05/03/2016 04:43 AM, Christoph Hellwig wrote: As explained in another thread I really think we need to get DAX to stop pretending to be direct I/O, which should also take care of the locking. The same issue also exists for ext2 and XFS so it needs to be solved at a higher level. I think

[PATCH v8 4/9] pwm: pwm-tiecap: Update dt binding document to use proper unit address

Replace unit address from 0 to the proper physical address. Also insure that the unit address matches the reg property address. Signed-off-by: Franklin S Cooper Jr --- Documentation/devicetree/bindings/pwm/pwm-tiecap.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [PATCH 2/2] pinctrl: ns2: rename pinctrl_utils_dt_free_map

Hi Arnd, On Tue, May 3, 2016 at 8:56 PM, Arnd Bergmann wrote: > A conflict of two patches caused a build error when a function got renamed > but a new user appeared in the other patch: > > drivers/pinctrl/bcm/pinctrl-ns2-mux.c:540:17: error: > 'pinctrl_utils_dt_free_map'

Re: [PATCH 2/2] pinctrl: ns2: rename pinctrl_utils_dt_free_map

Hi Arnd, On Tue, May 3, 2016 at 8:56 PM, Arnd Bergmann wrote: > A conflict of two patches caused a build error when a function got renamed > but a new user appeared in the other patch: > > drivers/pinctrl/bcm/pinctrl-ns2-mux.c:540:17: error: > 'pinctrl_utils_dt_free_map' undeclared here (not in

[PATCH] zram: remove max_comp_streams internals

Remove the internal part of max_comp_streams interface, since we switched to per-cpu streams. We will keep RW max_comp_streams attr around, because: a) we may (silently) switch back to idle compression streams list and don't want to disturb user space b) max_comp_streams attr must wait for the

[PATCH] zram: remove max_comp_streams internals

Remove the internal part of max_comp_streams interface, since we switched to per-cpu streams. We will keep RW max_comp_streams attr around, because: a) we may (silently) switch back to idle compression streams list and don't want to disturb user space b) max_comp_streams attr must wait for the

[PATCH v8 7/9] ARM: dts: am437x/am33xx: Remove hwmod entries for ECAP and EPWM nodes

Previous patches switched the ECAP and EPWM to use the new bindings. These bindings explicitly adds the various required clocks via DT rather than depending on hwmod. Therefore, it is safe to remove the hwmod entries since they are no longer needed. Signed-off-by: Franklin S Cooper Jr

[PATCH v8 8/9] ARM: AM335x/AM437x: hwmod: Remove eQEP, ePWM and eCAP hwmod entries

Devices that utilize the OCP registers and/or PRCM registers and register bit fields should be modeled using hwmod. Since eQEP, ePWM and eCAP don't fall under this category, remove their hwmod entries. Instead these clocks simply use the clock that is passed through by its parent PWMSS.

[PATCH v8 5/9] ARM: dts: am437x/am33xx/da850: Add new ECAP and EPWM bindings

Switch to a new ECAP and EPWM bindings that doesn't depend on hwmod to provide the various required clocks. For AM437 and AM335x, add the required clocks explicitly to DT. The hwmod entries for ECAP and EPWM will be removed and this will prevent anything from breaking. Signed-off-by: Franklin S

[PATCH v8 7/9] ARM: dts: am437x/am33xx: Remove hwmod entries for ECAP and EPWM nodes

Previous patches switched the ECAP and EPWM to use the new bindings. These bindings explicitly adds the various required clocks via DT rather than depending on hwmod. Therefore, it is safe to remove the hwmod entries since they are no longer needed. Signed-off-by: Franklin S Cooper Jr Acked-by:

[PATCH v8 8/9] ARM: AM335x/AM437x: hwmod: Remove eQEP, ePWM and eCAP hwmod entries

Devices that utilize the OCP registers and/or PRCM registers and register bit fields should be modeled using hwmod. Since eQEP, ePWM and eCAP don't fall under this category, remove their hwmod entries. Instead these clocks simply use the clock that is passed through by its parent PWMSS.

[PATCH v8 5/9] ARM: dts: am437x/am33xx/da850: Add new ECAP and EPWM bindings

Switch to a new ECAP and EPWM bindings that doesn't depend on hwmod to provide the various required clocks. For AM437 and AM335x, add the required clocks explicitly to DT. The hwmod entries for ECAP and EPWM will be removed and this will prevent anything from breaking. Signed-off-by: Franklin S

[PATCH v8 6/9] pwms: pwm-ti*: Get the clock from the PWMSS parent when using old bindings

When using the old eCAP and ePWM bindings for AM335x and AM437x the clock can be retrieved from the PWMSS parent. Newer bindings will insure that this clock is provided via device tree. Therefore, update this driver to support the newer and older bindings. In the case of the older binding being

[PATCH v8 6/9] pwms: pwm-ti*: Get the clock from the PWMSS parent when using old bindings

When using the old eCAP and ePWM bindings for AM335x and AM437x the clock can be retrieved from the PWMSS parent. Newer bindings will insure that this clock is provided via device tree. Therefore, update this driver to support the newer and older bindings. In the case of the older binding being

[PATCH v8 9/9] ARM: dts: DRA7: Add dt nodes for PWMSS

From: Vignesh R Add PWMSS device tree nodes for DRA7 SoC family and add documentation for dt bindings. Signed-off-by: Vignesh R [fcoo...@ti.com: Add eCAP and use updated bindings for PWMSS and ePWM] Signed-off-by: Franklin S Cooper Jr

[PATCH v8 1/9] clk: ti: am335x/am4372: Add tbclk to pwm node

Add tblck to the pwm nodes. This insures that the ehrpwm driver has access to the time-based clk. Do not remove similar entries for ehrpwm node. Later patches will switch from using ehrpwm node name to pwm. But to maintain ABI compatibility we shouldn't remove the old entries. Signed-off-by:

[PATCH v8 9/9] ARM: dts: DRA7: Add dt nodes for PWMSS

From: Vignesh R Add PWMSS device tree nodes for DRA7 SoC family and add documentation for dt bindings. Signed-off-by: Vignesh R [fcoo...@ti.com: Add eCAP and use updated bindings for PWMSS and ePWM] Signed-off-by: Franklin S Cooper Jr Acked-by: Rob Herring ---

[PATCH v8 1/9] clk: ti: am335x/am4372: Add tbclk to pwm node

Add tblck to the pwm nodes. This insures that the ehrpwm driver has access to the time-based clk. Do not remove similar entries for ehrpwm node. Later patches will switch from using ehrpwm node name to pwm. But to maintain ABI compatibility we shouldn't remove the old entries. Signed-off-by:

Re: [PATCH v5 0/3] mfd: max8997: add regmap support

Hi, On 17/02/2015 at 09:49:24 +0100, Robert Baldyga wrote : > Hi Alessandro, > > It looks like only your Ack is missing. Could you please look at my > patches? There are very little changes in RTC subsystem but your Ack is > needed. > I understand you are still waiting for acks from an RTC

Re: [PATCH v5 0/3] mfd: max8997: add regmap support

Hi, On 17/02/2015 at 09:49:24 +0100, Robert Baldyga wrote : > Hi Alessandro, > > It looks like only your Ack is missing. Could you please look at my > patches? There are very little changes in RTC subsystem but your Ack is > needed. > I understand you are still waiting for acks from an RTC

[char-misc-next] mei: bus: call mei_cl_read_start under device lock

From: Alexander Usyskin Ensure that mei_cl_read_start is called under the device lock also in the bus layer. The function updates global ctrl_wr_list which should be locked. Cc: #4.4+ Signed-off-by: Alexander Usyskin

[char-misc-next] mei: bus: call mei_cl_read_start under device lock

From: Alexander Usyskin Ensure that mei_cl_read_start is called under the device lock also in the bus layer. The function updates global ctrl_wr_list which should be locked. Cc: #4.4+ Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler --- drivers/misc/mei/bus.c | 15

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On 04/30/2016 01:13 AM, Elliott, Robert (Persistent Memory) wrote: >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >> ow...@vger.kernel.org] On Behalf Of Tom Lendacky >> Sent: Tuesday, April 26, 2016 5:56 PM >> Subject: [RFC PATCH v1 00/18] x86:

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On 04/30/2016 01:13 AM, Elliott, Robert (Persistent Memory) wrote: >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >> ow...@vger.kernel.org] On Behalf Of Tom Lendacky >> Sent: Tuesday, April 26, 2016 5:56 PM >> Subject: [RFC PATCH v1 00/18] x86:

Re: [PATCH v3 2/2] cgroup: allow management of subtrees by new cgroup namespaces

Hello, Aleksa. On Tue, May 03, 2016 at 11:52:22AM +1000, Aleksa Sarai wrote: > However, I agree with James that this patchset isn't ideal (it was my first > rough attempt). I think I'll get to work on properly virtualising > /sys/fs/cgroup, which will allow for a new cgroup namespace to modify >

Re: [PATCH v3 2/2] cgroup: allow management of subtrees by new cgroup namespaces

Hello, Aleksa. On Tue, May 03, 2016 at 11:52:22AM +1000, Aleksa Sarai wrote: > However, I agree with James that this patchset isn't ideal (it was my first > rough attempt). I think I'll get to work on properly virtualising > /sys/fs/cgroup, which will allow for a new cgroup namespace to modify >

Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

Andreas Dilger wrote: > > STATX_INFO_ENCRYPTEDFile is encrypted > > This flag overlaps with FS_ENCRYPT_FL that is encoded in the FS_IOC_GETFLAGS > attributes. Are the FS_* flags expected to be translated into STATX_INFO_* > flags by each filesystem, or will

Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

Andreas Dilger wrote: > > STATX_INFO_ENCRYPTEDFile is encrypted > > This flag overlaps with FS_ENCRYPT_FL that is encoded in the FS_IOC_GETFLAGS > attributes. Are the FS_* flags expected to be translated into STATX_INFO_* > flags by each filesystem, or will they be partly

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote: > On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote: > > On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault > > wrote: > > > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote: > > >> static

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote: > On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote: > > On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault > > wrote: > > > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote: > > >> static int ppp_open(struct

Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

Hey all, On 03-05-16 17:02, christo.ra...@gmail.com wrote: On Tuesday, May 3, 2016 at 4:14:41 PM UTC+3, Maxime Ripard wrote: Hi, On Tue, May 03, 2016 at 4:12:06 PM UTC+3, Christo Radev wrote: Hi to All, I have already solved and tested this issue on Armbian build. Find patches for both

Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

Hey all, On 03-05-16 17:02, christo.ra...@gmail.com wrote: On Tuesday, May 3, 2016 at 4:14:41 PM UTC+3, Maxime Ripard wrote: Hi, On Tue, May 03, 2016 at 4:12:06 PM UTC+3, Christo Radev wrote: Hi to All, I have already solved and tested this issue on Armbian build. Find patches for both

Re: [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range

On 03/05/2016:10:07:48 AM, Timur Tabi wrote: > Pratyush Anand wrote: > >In fact after supporting max_hw_heartbeat_ms, there should be no change for > >action=0 functionally. However, we would still need some changes for > >action=1. > > IMHO, action=1 is more of a debugging option, and not

Re: [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range

On 03/05/2016:10:07:48 AM, Timur Tabi wrote: > Pratyush Anand wrote: > >In fact after supporting max_hw_heartbeat_ms, there should be no change for > >action=0 functionally. However, we would still need some changes for > >action=1. > > IMHO, action=1 is more of a debugging option, and not

Re: [PATCH v2 1/3] ext4: Add alignment check for DAX mount

On Tue, 2016-05-03 at 08:43 -0600, Ross Zwisler wrote: > On Tue, May 03, 2016 at 11:00:21AM +0200, Jan Kara wrote: > > > > On Tue 03-05-16 01:44:10, Christoph Hellwig wrote: > > > > > > Please come up with a version that doesn't require tons of > > > boilerplate code in every file system. > > >

Re: [PATCH v2 1/3] ext4: Add alignment check for DAX mount

On Tue, 2016-05-03 at 08:43 -0600, Ross Zwisler wrote: > On Tue, May 03, 2016 at 11:00:21AM +0200, Jan Kara wrote: > > > > On Tue 03-05-16 01:44:10, Christoph Hellwig wrote: > > > > > > Please come up with a version that doesn't require tons of > > > boilerplate code in every file system. > > >

Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

On Tuesday, May 3, 2016 at 4:14:41 PM UTC+3, Maxime Ripard wrote: > Hi, > > On Tue, May 03, 2016 at 4:12:06 PM UTC+3, Christo Radev wrote: > > Hi to All, > > > > I have already solved and tested this issue on Armbian build. Find > > patches for both legacy (3.4.111) and mainline (4.5.2) kernels

Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

On Tuesday, May 3, 2016 at 4:14:41 PM UTC+3, Maxime Ripard wrote: > Hi, > > On Tue, May 03, 2016 at 4:12:06 PM UTC+3, Christo Radev wrote: > > Hi to All, > > > > I have already solved and tested this issue on Armbian build. Find > > patches for both legacy (3.4.111) and mainline (4.5.2) kernels

Re: [PATCH 7/8] wbt: add general throttling mechanism

On Tue 03-05-16 17:40:32, Jan Kara wrote: > On Tue 03-05-16 11:34:10, Jan Kara wrote: > > Yeah, once I'll hunt down that regression with old disk, I can have a look > > into how writeback throttling plays together with blkio-controller. > > So I've tried the following script (note that you need

Re: [PATCH 7/8] wbt: add general throttling mechanism

On Tue 03-05-16 17:40:32, Jan Kara wrote: > On Tue 03-05-16 11:34:10, Jan Kara wrote: > > Yeah, once I'll hunt down that regression with old disk, I can have a look > > into how writeback throttling plays together with blkio-controller. > > So I've tried the following script (note that you need

Re: 4.4: INFO: rcu_sched self-detected stall on CPU

On Wed, May 04, 2016 at 01:11:46AM +1000, Steven Haigh wrote: > On 03/05/16 06:54, gre...@linuxfoundation.org wrote: > > On Wed, Mar 30, 2016 at 05:04:28AM +1100, Steven Haigh wrote: > >> Greg, please see below - this is probably more for you... > >> > >> On 03/29/2016 04:56 AM, Steven Haigh

Re: 4.4: INFO: rcu_sched self-detected stall on CPU

On Wed, May 04, 2016 at 01:11:46AM +1000, Steven Haigh wrote: > On 03/05/16 06:54, gre...@linuxfoundation.org wrote: > > On Wed, Mar 30, 2016 at 05:04:28AM +1100, Steven Haigh wrote: > >> Greg, please see below - this is probably more for you... > >> > >> On 03/29/2016 04:56 AM, Steven Haigh

Re: [PATCH 09/18] ASoC: sti: Update DT example to match the driver code

On 04/26/2016 01:02 PM, Peter Griffin wrote: > Hi Mark, > > On Thu, 21 Apr 2016, Mark Brown wrote: > >> On Thu, Apr 21, 2016 at 12:04:26PM +0100, Peter Griffin wrote: >>> uniperiph-id, version and mode are ST specific bindings and >>> need the 'st,' prefix. Update the examples, as otherwise

Re: [PATCH 09/18] ASoC: sti: Update DT example to match the driver code

On 04/26/2016 01:02 PM, Peter Griffin wrote: > Hi Mark, > > On Thu, 21 Apr 2016, Mark Brown wrote: > >> On Thu, Apr 21, 2016 at 12:04:26PM +0100, Peter Griffin wrote: >>> uniperiph-id, version and mode are ST specific bindings and >>> need the 'st,' prefix. Update the examples, as otherwise

[PATCH] arm64: defconfig: Enable cros-ec and battery driver

Enable the ChromeOS Embedded Controller, its I2C tunnel driver, and the BA27XXX battery driver. These are all used on the Tegra210 Smaug platform. Signed-off-by: Rhyland Klein --- arch/arm64/configs/defconfig | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

Hi, On 03/05/16 10:06, Jun Li wrote: > Hi > > /** > + * usb_gadget_start - start the usb gadget controller and > +connect to bus > + * @gadget: the gadget device to start > + * > + * This is external API for use by OTG core. > + *

[PATCH] arm64: defconfig: Enable cros-ec and battery driver

Enable the ChromeOS Embedded Controller, its I2C tunnel driver, and the BA27XXX battery driver. These are all used on the Tegra210 Smaug platform. Signed-off-by: Rhyland Klein --- arch/arm64/configs/defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/configs/defconfig

Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

Hi, On 03/05/16 10:06, Jun Li wrote: > Hi > > /** > + * usb_gadget_start - start the usb gadget controller and > +connect to bus > + * @gadget: the gadget device to start > + * > + * This is external API for use by OTG core. > + *

Re: [PATCH v2 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

On Mon, May 2, 2016 at 2:58 PM, Dave Hansen wrote: > On 05/02/2016 02:41 PM, Thomas Garnier wrote: >> Minor change that allows early boot physical mapping of PUD level virtual >> addresses. This change prepares usage of different virtual addresses for >> KASLR memory

Re: [PATCH v2 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

On Mon, May 2, 2016 at 2:58 PM, Dave Hansen wrote: > On 05/02/2016 02:41 PM, Thomas Garnier wrote: >> Minor change that allows early boot physical mapping of PUD level virtual >> addresses. This change prepares usage of different virtual addresses for >> KASLR memory randomization. It has no

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On Tue, May 3, 2016 at 7:42 AM, David B. Robins wrote: > On 2016-05-03 00:55, John Stultz wrote: >> >> Looking through the commits since the v4.1 kernel where we didn't see >> this, I narrowed the regression down, and reverting the following two >> commits seems to avoid

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On Tue, May 3, 2016 at 7:42 AM, David B. Robins wrote: > On 2016-05-03 00:55, John Stultz wrote: >> >> Looking through the commits since the v4.1 kernel where we didn't see >> this, I narrowed the regression down, and reverting the following two >> commits seems to avoid the problem: >> >>

Re: [PATCH 7/8] wbt: add general throttling mechanism

On Tue 03-05-16 11:34:10, Jan Kara wrote: > Yeah, once I'll hunt down that regression with old disk, I can have a look > into how writeback throttling plays together with blkio-controller. So I've tried the following script (note that you need cgroup v2 for writeback IO to be throttled): ---

Re: [PATCH 7/8] wbt: add general throttling mechanism

On Tue 03-05-16 11:34:10, Jan Kara wrote: > Yeah, once I'll hunt down that regression with old disk, I can have a look > into how writeback throttling plays together with blkio-controller. So I've tried the following script (note that you need cgroup v2 for writeback IO to be throttled): ---

[PATCH net-next 5/5] net: remove dev->trans_start

previous patches removed all direct accesses to dev->trans_start, so change the netif_trans_update helper to update trans_start of netdev queue 0 instead and then remove trans_start from struct net_device. AFAICS a lot of the netif_trans_update() invocations are now useless because they occur in

[PATCH net-next 5/5] net: remove dev->trans_start

previous patches removed all direct accesses to dev->trans_start, so change the netif_trans_update helper to update trans_start of netdev queue 0 instead and then remove trans_start from struct net_device. AFAICS a lot of the netif_trans_update() invocations are now useless because they occur in

[PATCH 17/20] X86_64, UV: Build GAM reference tables

An aspect of the UV4 system architecture changes involve changing the way sockets, nodes, and pnodes are translated between one another. Decode the information from the BIOS provided EFI system table to build the needed conversion tables. Signed-off-by: Mike Travis Reviewed-by:

[PATCH 17/20] X86_64, UV: Build GAM reference tables

An aspect of the UV4 system architecture changes involve changing the way sockets, nodes, and pnodes are translated between one another. Decode the information from the BIOS provided EFI system table to build the needed conversion tables. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich

Re: [PATCH] kvm: robustify steal time record

2016-05-03 03:19+, Wanpeng Li: > From: Wanpeng Li > > Guest should only trust data to be valid when version haven't changed > before and after reads of steal time. Besides not changing, it has to > be an even number. Hypervisor may write an odd number to version

Re: [PATCH] kvm: robustify steal time record

2016-05-03 03:19+, Wanpeng Li: > From: Wanpeng Li > > Guest should only trust data to be valid when version haven't changed > before and after reads of steal time. Besides not changing, it has to > be an even number. Hypervisor may write an odd number to version field > to indicate that

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Sat 30-04-16 09:40:08, Dave Chinner wrote: > On Fri, Apr 29, 2016 at 02:12:20PM +0200, Michal Hocko wrote: [...] > > - was it > > "inconsistent {RECLAIM_FS-ON-[RW]} -> {IN-RECLAIM_FS-[WR]} usage" > > or a different class reports? > > Typically that was involved, but it quite often there'd be

Re: [PATCH 0/6] Intel Secure Guard Extensions

Hi! > We have been following and analyzing this technology since the first > HASP paper was published detailing its development. We have been (1) > > I told my associates the first time I reviewed this technology that > SGX has the ability to be a bit of a Pandora's box and it seems to be >

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Sat 30-04-16 09:40:08, Dave Chinner wrote: > On Fri, Apr 29, 2016 at 02:12:20PM +0200, Michal Hocko wrote: [...] > > - was it > > "inconsistent {RECLAIM_FS-ON-[RW]} -> {IN-RECLAIM_FS-[WR]} usage" > > or a different class reports? > > Typically that was involved, but it quite often there'd be

Re: [PATCH 0/6] Intel Secure Guard Extensions

Hi! > We have been following and analyzing this technology since the first > HASP paper was published detailing its development. We have been (1) > > I told my associates the first time I reviewed this technology that > SGX has the ability to be a bit of a Pandora's box and it seems to be >

Re: [PATCH] efivarfs: merge boolean flag arguments

On Thu, 21 Apr, at 03:24:29PM, Julia Lawall wrote: > The parameters atomic and duplicates of efivar_init always have opposite > values. Drop the parameter atomic, replace the uses of !atomic with > duplicates, and update the call sites accordingly. > > The code using duplicates is slightly

Re: [PATCH] efivarfs: merge boolean flag arguments

On Thu, 21 Apr, at 03:24:29PM, Julia Lawall wrote: > The parameters atomic and duplicates of efivar_init always have opposite > values. Drop the parameter atomic, replace the uses of !atomic with > duplicates, and update the call sites accordingly. > > The code using duplicates is slightly

<    4   5   6   7   8   9   10   11   12   13   >