Re: [PATCH] swiotlb: swiotlb_{alloc,free}_buffer should depend on CONFIG_DMA_DIRECT_OPS

On Sat, Mar 24, 2018 at 06:03:51PM +0100, Christoph Hellwig wrote: > On Fri, Mar 23, 2018 at 02:57:07PM -0400, Konrad Rzeszutek Wilk wrote: > > On Fri, Mar 23, 2018 at 06:49:30PM +0100, Christoph Hellwig wrote: > > > Otherwise we might get unused symbol warnings for configs that built > > >

Re: [PATCH] swiotlb: swiotlb_{alloc,free}_buffer should depend on CONFIG_DMA_DIRECT_OPS

On Sat, Mar 24, 2018 at 06:03:51PM +0100, Christoph Hellwig wrote: > On Fri, Mar 23, 2018 at 02:57:07PM -0400, Konrad Rzeszutek Wilk wrote: > > On Fri, Mar 23, 2018 at 06:49:30PM +0100, Christoph Hellwig wrote: > > > Otherwise we might get unused symbol warnings for configs that built > > >

Re: [PATCH v1 12/16] rtc: mediatek: cleanup header files to include

Hi Sean, I love your patch! Yet something to improve: [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.16-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v1 12/16] rtc: mediatek: cleanup header files to include

Hi Sean, I love your patch! Yet something to improve: [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.16-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 2/2] KVM: X86: Fix disable pv tlb flush when steal time is enabled

From: Wanpeng Li PV TLB FLUSH can be turned on when steal time is enabled. The condition reverse when the patch is sent out for several rounds review by mistake. This patch fixes it. Cc: Paolo Bonzini Cc: Radim Krčmář

[PATCH 2/2] KVM: X86: Fix disable pv tlb flush when steal time is enabled

From: Wanpeng Li PV TLB FLUSH can be turned on when steal time is enabled. The condition reverse when the patch is sent out for several rounds review by mistake. This patch fixes it. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kernel/kvm.c | 4 ++-- 1 file

Re: [PATCH v1 12/16] rtc: mediatek: cleanup header files to include

Hi Sean, I love your patch! Yet something to improve: [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.16-rc6 next-20180323] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 1/2] KVM: X86: Fix setup the virt_spin_lock_key before static key get initialized

From: Wanpeng Li static_key_disable_cpuslocked(): static key 'virt_spin_lock_key+0x0/0x20' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:161 static_key_disable_cpuslocked+0x61/0x80 RIP: 0010:static_key_disable_cpuslocked+0x61/0x80

Re: [PATCH v1 12/16] rtc: mediatek: cleanup header files to include

Hi Sean, I love your patch! Yet something to improve: [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.16-rc6 next-20180323] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 1/2] KVM: X86: Fix setup the virt_spin_lock_key before static key get initialized

From: Wanpeng Li static_key_disable_cpuslocked(): static key 'virt_spin_lock_key+0x0/0x20' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:161 static_key_disable_cpuslocked+0x61/0x80 RIP: 0010:static_key_disable_cpuslocked+0x61/0x80 Call Trace:

Re: [PATCH v1 11/16] rtc: mediatek: move the declaration into a globally visible header file

On Sat, 2018-03-24 at 17:00 -0300, Fabio Estevam wrote: > On Fri, Mar 23, 2018 at 6:15 AM, wrote: > > > --- /dev/null > > +++ b/include/linux/rtc/mt6397.h > > @@ -0,0 +1,72 @@ > > + > > +// SPDX-License-Identifier: GPL-2.0 > > According to

Re: [PATCH v1 11/16] rtc: mediatek: move the declaration into a globally visible header file

On Sat, 2018-03-24 at 17:00 -0300, Fabio Estevam wrote: > On Fri, Mar 23, 2018 at 6:15 AM, wrote: > > > --- /dev/null > > +++ b/include/linux/rtc/mt6397.h > > @@ -0,0 +1,72 @@ > > + > > +// SPDX-License-Identifier: GPL-2.0 > > According to Documentation/process/license-rules.rst the SPDX

Re: [v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

Hi, On 25 March 2018 at 12:21, Jonathan Liu wrote: > Hi, > > On 8 February 2018 at 14:55, Jeffy Chen wrote: >> From: AMAN DEEP >> >> There is a race condition between finish_unlinks->finish_urb() function >> and usb_kill_urb()

Re: [v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

Hi, On 25 March 2018 at 12:21, Jonathan Liu wrote: > Hi, > > On 8 February 2018 at 14:55, Jeffy Chen wrote: >> From: AMAN DEEP >> >> There is a race condition between finish_unlinks->finish_urb() function >> and usb_kill_urb() in ohci controller case. The finish_urb calls >> spin_unlock(>lock)

Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

On Wednesday 21 Mar 2018 at 15:35:18 (+), Patrick Bellasi wrote: > On 20-Mar 09:43, Dietmar Eggemann wrote: > > From: Quentin Perret > > [...] > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 76bd46502486..65a1bead0773 100644 > > ---

Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

On Wednesday 21 Mar 2018 at 15:35:18 (+), Patrick Bellasi wrote: > On 20-Mar 09:43, Dietmar Eggemann wrote: > > From: Quentin Perret > > [...] > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 76bd46502486..65a1bead0773 100644 > > --- a/kernel/sched/fair.c > > +++

Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

On Friday 23 Mar 2018 at 16:00:59 (+), Morten Rasmussen wrote: > On Thu, Mar 22, 2018 at 09:27:43AM -0700, Joel Fernandes wrote: > > Hi, > > > > On Tue, Mar 20, 2018 at 2:43 AM, Dietmar Eggemann > > wrote: [...] > > Is it possible that before the wakeup, the

Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

On Friday 23 Mar 2018 at 16:00:59 (+), Morten Rasmussen wrote: > On Thu, Mar 22, 2018 at 09:27:43AM -0700, Joel Fernandes wrote: > > Hi, > > > > On Tue, Mar 20, 2018 at 2:43 AM, Dietmar Eggemann > > wrote: [...] > > Is it possible that before the wakeup, the task's affinity is changed > >

Re: [PATCH 6/8] Pmalloc selftest

On 14/03/18 14:25, Matthew Wilcox wrote: > On Tue, Mar 13, 2018 at 11:45:52PM +0200, Igor Stoppa wrote: >> Add basic self-test functionality for pmalloc. > > Here're some additional tests for your test-suite: > > for (i = 1; i; i *= 2) > pzalloc(pool, i - 1, GFP_KERNEL); >

Re: [PATCH 6/8] Pmalloc selftest

On 14/03/18 14:25, Matthew Wilcox wrote: > On Tue, Mar 13, 2018 at 11:45:52PM +0200, Igor Stoppa wrote: >> Add basic self-test functionality for pmalloc. > > Here're some additional tests for your test-suite: > > for (i = 1; i; i *= 2) > pzalloc(pool, i - 1, GFP_KERNEL); >

[PATCH v2 2/2] drivers: soc: Add LLCC driver

LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into muliple slices and each slice getting its own priority, size, ID and other config parameters. LLCC driver programs these parameters for each slice. Clients that are assigned to use LLCC need

[PATCH v2 0/2] SDM845 System Cache Driver

This series implements system cache or LLCC(Last Level Cache Controller) driver for SDM845 SOC. The purpose of the driver is to partition the system cache and program the settings such as priortiy, lines to probe while doing a look up in the system cache, low power related settings etc. The

[PATCH v2 0/2] SDM845 System Cache Driver

This series implements system cache or LLCC(Last Level Cache Controller) driver for SDM845 SOC. The purpose of the driver is to partition the system cache and program the settings such as priortiy, lines to probe while doing a look up in the system cache, low power related settings etc. The

[PATCH v2 2/2] drivers: soc: Add LLCC driver

LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into muliple slices and each slice getting its own priority, size, ID and other config parameters. LLCC driver programs these parameters for each slice. Clients that are assigned to use LLCC need

[PATCH v2 1/2] Documentation: Documentation for qcom, llcc

Documentation for last level cache controller device tree bindings, client bindings usage examples. Change-Id: Ic2d6d6154ab8269cfce6828e9f2250320a0572e8 Signed-off-by: Channagoud Kadabi Signed-off-by: Rishabh Bhatnagar ---

[PATCH v2 1/2] Documentation: Documentation for qcom, llcc

Documentation for last level cache controller device tree bindings, client bindings usage examples. Change-Id: Ic2d6d6154ab8269cfce6828e9f2250320a0572e8 Signed-off-by: Channagoud Kadabi Signed-off-by: Rishabh Bhatnagar --- .../devicetree/bindings/arm/msm/qcom,llcc.txt | 70

[GIT PULL] Revert "mqueue: switch to on-demand creation of internal mount"

Linus, Please pull the for-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus HEAD: cfb2f6f6e0ba11ea7b263d6b69c170c4b32ac0ea Revert "mqueue: switch to on-demand creation of internal mount" This fixes a regression that

[GIT PULL] Revert "mqueue: switch to on-demand creation of internal mount"

Linus, Please pull the for-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus HEAD: cfb2f6f6e0ba11ea7b263d6b69c170c4b32ac0ea Revert "mqueue: switch to on-demand creation of internal mount" This fixes a regression that

Re: [v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

Hi, On 8 February 2018 at 14:55, Jeffy Chen wrote: > From: AMAN DEEP > > There is a race condition between finish_unlinks->finish_urb() function > and usb_kill_urb() in ohci controller case. The finish_urb calls > spin_unlock(>lock) before

Re: [v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

Hi, On 8 February 2018 at 14:55, Jeffy Chen wrote: > From: AMAN DEEP > > There is a race condition between finish_unlinks->finish_urb() function > and usb_kill_urb() in ohci controller case. The finish_urb calls > spin_unlock(>lock) before usb_hcd_giveback_urb() function call, > then if during

RE: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX path

> -Original Message- > From: Michael Kelley (EOSG) > Sent: Saturday, March 24, 2018 12:48 PM > To: Haiyang Zhang ; da...@davemloft.net; > net...@vger.kernel.org > Cc: KY Srinivasan ; Stephen Hemminger > ; o...@aepfle.de;

RE: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX path

> -Original Message- > From: Michael Kelley (EOSG) > Sent: Saturday, March 24, 2018 12:48 PM > To: Haiyang Zhang ; da...@davemloft.net; > net...@vger.kernel.org > Cc: KY Srinivasan ; Stephen Hemminger > ; o...@aepfle.de; vkuzn...@redhat.com; > de...@linuxdriverproject.org;

Re: [PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On 3/23/18 9:30 PM, Matthew Wilcox wrote: So, introduce a new rwlock in mm_struct to protect the concurrent access to arg_start|end and env_start|end. I don't think an rwlock makes much sense here. There is almost no concurrency on the read side, and an rwlock is more expensive than a

Re: [PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On 3/23/18 9:30 PM, Matthew Wilcox wrote: So, introduce a new rwlock in mm_struct to protect the concurrent access to arg_start|end and env_start|end. I don't think an rwlock makes much sense here. There is almost no concurrency on the read side, and an rwlock is more expensive than a

RE: [PATCH v3] cpuidle: poll_state: Add time limit to poll_idle()

On 2018.03.14 07:04 Rafael J. Wysocki wrote: > If poll_idle() is allowed to spin until need_resched() returns 'true', > it may actually spin for a much longer time than expected by the idle > governor, since set_tsk_need_resched() is not always called by the > timer interrupt handler. If that

RE: [PATCH v3] cpuidle: poll_state: Add time limit to poll_idle()

On 2018.03.14 07:04 Rafael J. Wysocki wrote: > If poll_idle() is allowed to spin until need_resched() returns 'true', > it may actually spin for a much longer time than expected by the idle > governor, since set_tsk_need_resched() is not always called by the > timer interrupt handler. If that

Re: [PATCH net-next v2 2/2] cxgb4: collect hardware dump in second kernel

Thadeu Lima de Souza Cascardo writes: > On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote: >> Register callback to collect hardware/firmware dumps in second kernel >> before hardware/firmware is initialized. The dumps for each device >> will be available

Re: [PATCH net-next v2 2/2] cxgb4: collect hardware dump in second kernel

Thadeu Lima de Souza Cascardo writes: > On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote: >> Register callback to collect hardware/firmware dumps in second kernel >> before hardware/firmware is initialized. The dumps for each device >> will be available under

Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

On Fri, Mar 23, 2018 at 6:47 PM, Quentin Perret wrote: > On Thursday 22 Mar 2018 at 13:19:03 (-0700), Joel Fernandes wrote: >> On Thu, Mar 22, 2018 at 11:06 AM, Patrick Bellasi >> wrote: > > [...] > >> >> > @@ -6555,6 +6613,14 @@

Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

On Fri, Mar 23, 2018 at 6:47 PM, Quentin Perret wrote: > On Thursday 22 Mar 2018 at 13:19:03 (-0700), Joel Fernandes wrote: >> On Thu, Mar 22, 2018 at 11:06 AM, Patrick Bellasi >> wrote: > > [...] > >> >> > @@ -6555,6 +6613,14 @@ select_task_rq_fair(struct task_struct *p, int >> >> > prev_cpu,

Re: [REVIEW][PATCH 13/11] ipc/smack: Tidy up from the change in type of the ipc security hooks

On 3/23/2018 10:42 PM, Eric W. Biederman wrote: > Rename the variables shp, sma, msq to isp. As that is how the code already > refers to those variables. Thanks. It's important to keep the code readable. > Collapse smack_of_shm, smack_of_sem, and smack_of_msq into smack_of_ipc, > as the three

Re: [REVIEW][PATCH 13/11] ipc/smack: Tidy up from the change in type of the ipc security hooks

On 3/23/2018 10:42 PM, Eric W. Biederman wrote: > Rename the variables shp, sma, msq to isp. As that is how the code already > refers to those variables. Thanks. It's important to keep the code readable. > Collapse smack_of_shm, smack_of_sem, and smack_of_msq into smack_of_ipc, > as the three

[PATCH v2] gpio: ath79: Fix potential NULL dereference in ath79_gpio_probe()

From: Wei Yongjun platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = platform_get_resource(pdev, t, n); + if (!res) +

[PATCH v2] gpio: ath79: Fix potential NULL dereference in ath79_gpio_probe()

From: Wei Yongjun platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = platform_get_resource(pdev, t, n); + if (!res) + return -EINVAL; ... when !=

[PATCH v3 3/3] mtd: Add support for reading MTD devices via the nvmem API

Allow drivers that use the nvmem API to read data stored on MTD devices. For this the mtd devices are registered as read-only NVMEM providers. On OF systems only devices that have the 'nvmem-provider' property are registered, on non-OF system all MTD devices are registered. Signed-off-by: Alban

[PATCH v3 2/3] doc: bindings: Add bindings documentation for mtd nvmem

Config data for drivers, like MAC addresses, is often stored in MTD. Add a binding that define how such data storage can be represented in device tree. Signed-off-by: Alban Bedel --- Changelog: v2: * Added a "Required properties" section with the nvmem-provider property v3:

[PATCH v3 3/3] mtd: Add support for reading MTD devices via the nvmem API

Allow drivers that use the nvmem API to read data stored on MTD devices. For this the mtd devices are registered as read-only NVMEM providers. On OF systems only devices that have the 'nvmem-provider' property are registered, on non-OF system all MTD devices are registered. Signed-off-by: Alban

[PATCH v3 2/3] doc: bindings: Add bindings documentation for mtd nvmem

Config data for drivers, like MAC addresses, is often stored in MTD. Add a binding that define how such data storage can be represented in device tree. Signed-off-by: Alban Bedel --- Changelog: v2: * Added a "Required properties" section with the nvmem-provider property v3: * Fixed my name

[PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list

Having the cells as subnodes of the provider device without any compatible property might clash with other bindings. To avoid this problem update the binding to have all the cells in a 'nvmem-cells' subnode with a 'nvmem-cells' compatible string. This new binding guarantee that we can turn any

[PATCH v3 0/3] mtd: Add support for reading MTD devices via the nvmem API

Hi all, this series add support for reading MTD devices via the nvmem API, this is mostly needed on embedded devices where things like MAC address and calibration data is often stored in a partition on the main flash device. Adding support for the nvmem API to the MTD core is trivial, however

[PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list

Having the cells as subnodes of the provider device without any compatible property might clash with other bindings. To avoid this problem update the binding to have all the cells in a 'nvmem-cells' subnode with a 'nvmem-cells' compatible string. This new binding guarantee that we can turn any

[PATCH v3 0/3] mtd: Add support for reading MTD devices via the nvmem API

Hi all, this series add support for reading MTD devices via the nvmem API, this is mostly needed on embedded devices where things like MAC address and calibration data is often stored in a partition on the main flash device. Adding support for the nvmem API to the MTD core is trivial, however

Re: [PATCH v5 2/2] i2c: add support for Socionext SynQuacer I2C controller

My code checkers mention this: CPPCHECK drivers/i2c/busses/i2c-synquacer.c:422: style: Checking if unsigned variable 'timeout' is less than zero. CC drivers/i2c/busses/i2c-synquacer.o drivers/i2c/busses/i2c-synquacer.c: In function ‘synquacer_i2c_probe’:

Re: [PATCH v5 2/2] i2c: add support for Socionext SynQuacer I2C controller

My code checkers mention this: CPPCHECK drivers/i2c/busses/i2c-synquacer.c:422: style: Checking if unsigned variable 'timeout' is less than zero. CC drivers/i2c/busses/i2c-synquacer.o drivers/i2c/busses/i2c-synquacer.c: In function ‘synquacer_i2c_probe’:

[RFC PATCH] iommu/vt-d: intel_iommu_page_response() can be static

Fixes: 49c5977b4ee7 ("iommu/vt-d: add intel iommu page response function") Signed-off-by: Fengguang Wu --- intel-iommu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index

[RFC PATCH] iommu/vt-d: intel_iommu_page_response() can be static

Fixes: 49c5977b4ee7 ("iommu/vt-d: add intel iommu page response function") Signed-off-by: Fengguang Wu --- intel-iommu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 8d73ff0..06be796 100644 ---

Re: [PATCH v4 20/22] iommu/vt-d: add intel iommu page response function

Hi Jacob, I love your patch! Perhaps something to improve: [auto build test WARNING on iommu/next] [also build test WARNING on v4.16-rc6 next-20180323] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v4 20/22] iommu/vt-d: add intel iommu page response function

Hi Jacob, I love your patch! Perhaps something to improve: [auto build test WARNING on iommu/next] [also build test WARNING on v4.16-rc6 next-20180323] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v5 2/2] i2c: add support for Socionext SynQuacer I2C controller

Hi Ard, > +static int synquacer_i2c_master_start(struct synquacer_i2c *i2c, > + struct i2c_msg *pmsg) > +{ > + unsigned char bsr, bcr; > + > + if (pmsg->flags & I2C_M_RD) > + writeb((pmsg->addr << 1) | 1, > +i2c->base +

Re: [PATCH v5 2/2] i2c: add support for Socionext SynQuacer I2C controller

Hi Ard, > +static int synquacer_i2c_master_start(struct synquacer_i2c *i2c, > + struct i2c_msg *pmsg) > +{ > + unsigned char bsr, bcr; > + > + if (pmsg->flags & I2C_M_RD) > + writeb((pmsg->addr << 1) | 1, > +i2c->base +

Re: [PATCH 1/3] ieee80211: Replace bit shifts with the BIT() macro for WLAN_CAPABILITY_*.

The "document" refers to the file in which the changes were made ('include/linux/ieee80211.h'). I tend to try to split my commits into the smallest logically related changes possible, hence the three patch series. This particular case may be a little on the extreme side, but if the maintainer

Re: [PATCH 1/3] ieee80211: Replace bit shifts with the BIT() macro for WLAN_CAPABILITY_*.

The "document" refers to the file in which the changes were made ('include/linux/ieee80211.h'). I tend to try to split my commits into the smallest logically related changes possible, hence the three patch series. This particular case may be a little on the extreme side, but if the maintainer

Re: [PATCH v2 0/6] Add different features for I2C

On Wed, Mar 21, 2018 at 05:48:54PM +0100, Pierre-Yves MORDRET wrote: > Append new I2C STM32F7 feature set. This includes 10 bit support, slave > support, SMBBus protocols support, DMA Support and eventually an I2C recovery > mechanism. So, I gave a few comments. For hardware details (especially

Re: [PATCH v2 0/6] Add different features for I2C

On Wed, Mar 21, 2018 at 05:48:54PM +0100, Pierre-Yves MORDRET wrote: > Append new I2C STM32F7 feature set. This includes 10 bit support, slave > support, SMBBus protocols support, DMA Support and eventually an I2C recovery > mechanism. So, I gave a few comments. For hardware details (especially

Re: [PATCH v2 6/6] i2c: i2c-stm32f7: Implement I2C recovery mechanism

On Wed, Mar 21, 2018 at 05:49:00PM +0100, Pierre-Yves MORDRET wrote: > Feature prevents I2C lock-ups. Mechanism resets I2C state machine > and releases SCL/SDA signals but preserves I2C registers. > > Signed-off-by: Pierre-Yves MORDRET > --- > Version history: >

Re: [PATCH v2 6/6] i2c: i2c-stm32f7: Implement I2C recovery mechanism

On Wed, Mar 21, 2018 at 05:49:00PM +0100, Pierre-Yves MORDRET wrote: > Feature prevents I2C lock-ups. Mechanism resets I2C state machine > and releases SCL/SDA signals but preserves I2C registers. > > Signed-off-by: Pierre-Yves MORDRET > --- > Version history: > v1: >* Initial >

Re: [PATCH v2 4/6] i2c: i2c-stm32: Add generic DMA API

On Wed, Mar 21, 2018 at 05:48:58PM +0100, Pierre-Yves MORDRET wrote: > This patch adds a generic DMA API to implement DMA support for i2c-stm32fx > drivers > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET In

Re: [PATCH v2 4/6] i2c: i2c-stm32: Add generic DMA API

On Wed, Mar 21, 2018 at 05:48:58PM +0100, Pierre-Yves MORDRET wrote: > This patch adds a generic DMA API to implement DMA support for i2c-stm32fx > drivers > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET In case you haven't read it so far, there is a new

Re: [PATCH v2 3/6] i2c: i2c-stm32f7: Add initial SMBus protocols support

On Wed, Mar 21, 2018 at 05:48:57PM +0100, Pierre-Yves MORDRET wrote: > This patch adds SMBus support for I2C controller embedded in STM32F7 Soc. > All SMBus protocols are implemented except SMBus-specific protocols. What does that mean? > > Signed-off-by: M'boumba Cedric Madianga

Re: [PATCH v2 3/6] i2c: i2c-stm32f7: Add initial SMBus protocols support

On Wed, Mar 21, 2018 at 05:48:57PM +0100, Pierre-Yves MORDRET wrote: > This patch adds SMBus support for I2C controller embedded in STM32F7 Soc. > All SMBus protocols are implemented except SMBus-specific protocols. What does that mean? > > Signed-off-by: M'boumba Cedric Madianga >

Charity

I have a mission worth $ 100,000,000.00 for you

Charity

I have a mission worth $ 100,000,000.00 for you

[PATCH] usb: host: Remove the deprecated ATH79 USB host config options

The options USB_EHCI_ATH79 and USB_OHCI_ATH79 only enable the generic EHCI and OHCI platform drivers, and have been marked as deprecated since 2012. These can be safely removed if we make sure that USB_EHCI_ROOT_HUB_TT still get enabled for the EHCI driver. This is now done be selecting this

[PATCH] usb: host: Remove the deprecated ATH79 USB host config options

The options USB_EHCI_ATH79 and USB_OHCI_ATH79 only enable the generic EHCI and OHCI platform drivers, and have been marked as deprecated since 2012. These can be safely removed if we make sure that USB_EHCI_ROOT_HUB_TT still get enabled for the EHCI driver. This is now done be selecting this

Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

> On Mar 24, 2018, at 8:02 AM, Jonathan Cameron wrote: > > On Mon, 19 Mar 2018 22:57:16 -0700 > John Syne wrote: > >> Hi Jonathan, >> >> Thank you for all your hard work. Your feedback is really helpful. I’m >> surprised that no one from Analog Device

Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

> On Mar 24, 2018, at 8:02 AM, Jonathan Cameron wrote: > > On Mon, 19 Mar 2018 22:57:16 -0700 > John Syne wrote: > >> Hi Jonathan, >> >> Thank you for all your hard work. Your feedback is really helpful. I’m >> surprised that no one from Analog Device has offered any suggestions. >> > >

Re: [PATCH v2 1/6] i2c: i2c-stm32f7: Add 10-bit address support

On Wed, Mar 21, 2018 at 05:48:55PM +0100, Pierre-Yves MORDRET wrote: > This patch adds support for 10-bit device address for STM32F7 I2C > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET Out of curiosity: how

Re: [PATCH v2 1/6] i2c: i2c-stm32f7: Add 10-bit address support

On Wed, Mar 21, 2018 at 05:48:55PM +0100, Pierre-Yves MORDRET wrote: > This patch adds support for 10-bit device address for STM32F7 I2C > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET Out of curiosity: how did you test this patch? I never managed to find a

[PATCH] phy: Add a driver for the ATH79 USB phy

The ATH79 USB phy is very simple, it only have a reset. On some SoC a second reset is used to force the phy in suspend mode regardless of the USB controller status. This driver is added to the qualcom directory as atheros is now part of qualcom and newer SoC of this familly are marketed under the

[PATCH] phy: Add a driver for the ATH79 USB phy

The ATH79 USB phy is very simple, it only have a reset. On some SoC a second reset is used to force the phy in suspend mode regardless of the USB controller status. This driver is added to the qualcom directory as atheros is now part of qualcom and newer SoC of this familly are marketed under the

Re: [PATCH v3 01/11] i2c: Export of_i2c_get_board_info()

> > - info.archdata = _ad; > > Why did you drop this? If the removal is safe, it should be a seperate patch, I mean. signature.asc Description: PGP signature

Re: [PATCH v3 01/11] i2c: Export of_i2c_get_board_info()

> > - info.archdata = _ad; > > Why did you drop this? If the removal is safe, it should be a seperate patch, I mean. signature.asc Description: PGP signature

Re: efisubsys_init takes more than a few milliseconds

Hello Paul, On 24 March 2018 at 22:10, Paul Menzel wrote: > Dear Ard, > > > According to `initcall_debug`, `efisubsys_init` takes more than a few > milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7-8550U > CPU @ 1.80GHz). > >> ``` >> […] >> [

Re: efisubsys_init takes more than a few milliseconds

Hello Paul, On 24 March 2018 at 22:10, Paul Menzel wrote: > Dear Ard, > > > According to `initcall_debug`, `efisubsys_init` takes more than a few > milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7-8550U > CPU @ 1.80GHz). > >> ``` >> […] >> [ 0.144474] calling

Re: [PATCH v3 01/11] i2c: Export of_i2c_get_board_info()

Hi Boris, > - rebase on v4.15-rc1 This code has changed a little meanwhile. Please check my for-next branch. Some changes are identical, some similar. > - info.archdata = _ad; Why did you drop this? Regards, Wolfram signature.asc Description: PGP signature

Re: [PATCH v3 01/11] i2c: Export of_i2c_get_board_info()

Hi Boris, > - rebase on v4.15-rc1 This code has changed a little meanwhile. Please check my for-next branch. Some changes are identical, some similar. > - info.archdata = _ad; Why did you drop this? Regards, Wolfram signature.asc Description: PGP signature

Re: [PATCH net-next v2 2/2] cxgb4: collect hardware dump in second kernel

On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote: > Register callback to collect hardware/firmware dumps in second kernel > before hardware/firmware is initialized. The dumps for each device > will be available under /sys/kernel/crashdd/cxgb4/ directory in second > kernel. > >

Re: [PATCH net-next v2 2/2] cxgb4: collect hardware dump in second kernel

On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote: > Register callback to collect hardware/firmware dumps in second kernel > before hardware/firmware is initialized. The dumps for each device > will be available under /sys/kernel/crashdd/cxgb4/ directory in second > kernel. > >

efisubsys_init takes more than a few milliseconds

Dear Ard, According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz). ``` […] [0.144474] calling efisubsys_init+0x0/0x2cf @ 1 [0.144474] Registered efivars operations [0.173690]

efisubsys_init takes more than a few milliseconds

Dear Ard, According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz). ``` […] [0.144474] calling efisubsys_init+0x0/0x2cf @ 1 [0.144474] Registered efivars operations [0.173690]

[PATCH] staging: pi433: cleanup tx_fifo locking

pi433_write requires locking due to multiple kfifo writers. After acquiring the lock check if enough free space is available in the kfifo to write the whole message. This check should prevent partial writes to kfifo so kfifo_reset is not needed anymore. pi433_tx_thread is the only kfifo reader

[PATCH] staging: pi433: cleanup tx_fifo locking

pi433_write requires locking due to multiple kfifo writers. After acquiring the lock check if enough free space is available in the kfifo to write the whole message. This check should prevent partial writes to kfifo so kfifo_reset is not needed anymore. pi433_tx_thread is the only kfifo reader

Re: [PATCH] ftrace: fix stddev calculation in function profiler (again)

On 03/24/2018 05:26 PM, Matthias Schiffer wrote: > It is well-known that it is not possible to accurately calculate variances > just by accumulating squared samples; in fact, such an approach can even > result in negative numbers. An earlier attempt to fix the calculation > referred to Welford's

Re: [PATCH] ftrace: fix stddev calculation in function profiler (again)

On 03/24/2018 05:26 PM, Matthias Schiffer wrote: > It is well-known that it is not possible to accurately calculate variances > just by accumulating squared samples; in fact, such an approach can even > result in negative numbers. An earlier attempt to fix the calculation > referred to Welford's

Re: [PATCH 1/2] fs: Extend mount_ns with support for a fast namespace to vfsmount function

On Sat, Mar 24, 2018 at 11:12:02AM -0500, Eric W. Biederman wrote: > > This is completely wrong. Look: > > * SB_KERNMOUNT and !SB_KERNMOUNT cases are almost entirely isolated; > > completely so once that ns_to_mnt becomes unconditionally non-NULL. > > * in !SB_KERNMOUNT passing

Re: [PATCH 1/2] fs: Extend mount_ns with support for a fast namespace to vfsmount function

On Sat, Mar 24, 2018 at 11:12:02AM -0500, Eric W. Biederman wrote: > > This is completely wrong. Look: > > * SB_KERNMOUNT and !SB_KERNMOUNT cases are almost entirely isolated; > > completely so once that ns_to_mnt becomes unconditionally non-NULL. > > * in !SB_KERNMOUNT passing

**Herzlichen Glückwunsch**

Herzlichen Glückwunsch, Sie haben 650.000 Euro in den monatlichen Gewinnspielen von Euro Millions/Google Promo am 10. März 2018 gewonnen. Kontaktieren Sie unseren Schadenregulierungsbeauftragten mit den folgenden Informationen Vollständiger Name Heimatadresse Geschlecht Alter Telefon

**Herzlichen Glückwunsch**

Herzlichen Glückwunsch, Sie haben 650.000 Euro in den monatlichen Gewinnspielen von Euro Millions/Google Promo am 10. März 2018 gewonnen. Kontaktieren Sie unseren Schadenregulierungsbeauftragten mit den folgenden Informationen Vollständiger Name Heimatadresse Geschlecht Alter Telefon

[PATCH] x86/purgatory: Remove -MD from KBUILD_CFLAGS

The kernel build system already takes care of generating the dependency files. Having the additional -MD in KBUILD_CFLAGS leads to stray ..d files in the build directory when we call the cc-option macro. Signed-off-by: Sven Wegener --- arch/x86/purgatory/Makefile | 2

[PATCH] x86/purgatory: Remove -MD from KBUILD_CFLAGS

The kernel build system already takes care of generating the dependency files. Having the additional -MD in KBUILD_CFLAGS leads to stray ..d files in the build directory when we call the cc-option macro. Signed-off-by: Sven Wegener --- arch/x86/purgatory/Makefile | 2 +- 1 file changed, 1

  1   2   3   4   5   6   7   >